1 Estrategia, tcnicas y mtodos de prueba clsicos..........................................................2 1.1 Un enfoque estratgico para las pruebas del software.............................................2 1.1.

1 Verificacin y validacin (V&V).....................................................................3 1.1.2 Organizacin para las pruebas del software.....................................................3 1.1.3 Una estrategia de prueba del software..............................................................3 1.1.4 Criterios para completar la prueba....................................................................4 1.2 Aspectos estratgicos...............................................................................................4 1.3 Prueba de unidad.....................................................................................................4 1.3.1 Consideraciones sobre la prueba de unidad......................................................4 1.3.2 Procedimientos de Prueba de unidad................................................................5 1.4 Prueba de integracin..............................................................................................5 1.4.1 Integracin descendente...................................................................................5 1.4.2 Integracin ascendente.....................................................................................6 1.4.3 Prueba de regresin..........................................................................................6 1.4.4 Prueba de humo................................................................................................6 1.4.5 Comentarios sobre la prueba de integracin.....................................................6 1.5 Prueba de validacin................................................................................................6 1.5.1 Criterios para la prueba de validacin..............................................................7 1.5.2 Revisin de la configuracin............................................................................7 1.5.3 Pruebas alfa y beta............................................................................................7 1.6 Prueba del sistema...................................................................................................7 1.6.1 Prueba de recuperacin.....................................................................................7 1.6.2 Prueba de seguridad..........................................................................................7 1.6.3 Prueba de resistencia (Stress)...........................................................................8 1.6.4 Prueba de rendimiento......................................................................................8 1.7 Fundamentos de las pruebas del software...............................................................8 1.7.1 Objetivo de las pruebas....................................................................................8 1.7.2 Principios de las pruebas..................................................................................8 1.7.3 Facilidad de prueba...........................................................................................8 1.8 Diseo de casos de prueba.....................................................................................10 1.9 Prueba de Caja Blanca...........................................................................................10 1.10 Prueba del Camino Bsico...................................................................................10 1.10.1 Notacin del grafo de flujo...........................................................................10 1.10.2 Complejidad ciclomtica..............................................................................11 1.10.3 Obtencin de casos de pruebas.....................................................................11 1.10.4 Matrices de grafos........................................................................................12 1.11 Prueba de la estructura de control........................................................................12 1.11.1 Prueba de condicin......................................................................................12 1.11.2 Prueba de flujo de datos................................................................................13 1.11.3 Prueba de bucles...........................................................................................13 1.12 Prueba de Caja Negra..........................................................................................14 1.12.1 Mtodos de prueba basados en grafos..........................................................14 1.12.2 Particin equivalente....................................................................................14 1.12.3 Anlisis de valores lmite.............................................................................15 1.12.4 Prueba de comparacin.................................................................................15 1.12.5 Prueba de la tabla ortogonal.........................................................................15 1.13 Prueba de Entornos Especializados, Arquitecturas y Aplicaciones.....................15 1.13.1 Prueba de interfaces grficas de usuario (IGUs)..........................................15 1.13.2 Pruebas de arquitectura cliente / servidor.....................................................15 1.13.3 Pruebas de la documentacin y facilidades de ayuda...................................15

1.13.4 Prueba de sistemas de tiempo-real................................................................15 2 Pruebas orientadas a objetos.....................................................................................16 2.1 Ampliando la visin de las pruebas.......................................................................16 2.2 Pruebas de los Modelos de AOO y DOO..............................................................16 2.2.1 Exactitud de los modelos AOO y DOO..........................................................16 2.2.2 Consistencia de los modelos AOO y DOO....................................................16 2.3 Estrategias de Prueba Orientadas a Objetos..........................................................17 2.3.1 Las pruebas de unidad en el contexto de la OO.............................................17 2.3.2 Las pruebas de integracin en el contexto OO...............................................17 2.3.3 Pruebas de validacin en un contexto OO......................................................17 2.4 Diseo de Casos de Prueba para software OO......................................................17 2.4.1 Implicaciones de los conceptos de OO al diseo de casos de prueba............18 2.4.2 Aplicabilidad de los mtodos convencionales de diseo de casos de prueba.18 2.4.3 Pruebas basadas en errores.............................................................................18 2.4.4 El impacto de la programacin OO en las pruebas........................................18 2.4.5 Casos de prueba y jerarqua de clases............................................................18 2.4.6 Diseo de pruebas basadas en el escenario....................................................18 2.4.7 Las estructuras de pruebas superficiales y profundas.....................................19 2.5 Mtodos de Prueba aplicables a nivel de Clases...................................................19 2.5.1 La verificacin al azar para clases OO...........................................................19 2.5.2 Prueba de particin al nivel de clases.............................................................19 2.6 Diseo de Casos de prueba Interclase...................................................................19 2.6.1 Prueba de mltiples clases..............................................................................19 2.6.2 Prueba derivada de los modelos de comportamiento.....................................20 3 Pruebas de entornos especializados..........................................................................20 4 Patrones de prueba....................................................................................................20 5 Documentacin de pruebas.......................................................................................20 5.1 Plan de pruebas......................................................................................................20

1 Estrategia, tcnicas y mtodos de prueba clsicos.

Una estrategia de prueba del software integra las tcnicas de diseo de casos de prueba en una serie de pasos bien planificados que dan como resultado una correcta construccin del software.

1.1

Un enfoque estratgico para las pruebas del software

Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemticamente. Se debe definir en el proceso de ingeniera del software una plantilla para las pruebas del software: un conjunto de pasos en los que podamos situar los mtodos especficos de diseo de casos de prueba: Plantilla para la prueba: Las pruebas comienzan a nivel de mdulo y trabajan "hacia fuera", hacia la integracin de todo el sistema basado en computadora Segn el momento, son apropiadas diferentes tcnicas de prueba.

La prueba la lleva a cabo el responsable del desarrollo del software y un grupo independiente de pruebas. La prueba y la depuracin son actividades diferentes, pero la depuracin se debe incluir en cualquier estrategia de prueba.

1.1.1 Verificacin y validacin (V&V)

Verificaci n : se refiere al conjunto de actividades que aseguran que el software implementa correctamente una funcin especfica. Validaci n: se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente.

La verificacin y la validacin abarcan una amplia lista de actividades de SQA (garanta de calidad del software) que incluyen: 1. revisiones tcnicas formales 2. auditorias de calidad y de configuracin 3. monitorizacin de rendimientos 3. simulacin 4. estudios de factibilidad 5. revisin de la documentacin 6. revisin de la base de datos 7. anlisis de algoritmos 8. pruebas de desarrollo 9. pruebas de validacin 10. pruebas de instalacin La calidad se incorpora en el software durante el proceso de ingeniera del software. La calidad se confirma durante las pruebas.

1.1.2 Organizacin para las pruebas del software

Desde un punto de vista psicolgico, el anlisis y el diseo del software son tareas constructivas. Cuando comienza la prueba, aparece una sutil, aunque firma intencin de "romper" lo que el ingeniero a construido. El responsable del desarrollo del software siempre es responsable de probar las unidades individuales (mdulos) del programa, asegurndose de que cada una lleve a cabo la funcin para la que fue diseada. Solo una vez que la arquitectura del software est completa entra en juego un grupo independiente de prueba. Grupo independiente de prueba (GIP) : Una prueba independiente elimina el conflicto de intereses.

1.1.3 Una estrategia de prueba del software

El proceso de ingeniera del software se puede ver como una espiral. Inicialmente, la ingeniera de sistemas define el papel del software y conduce al anlisis de los requisitos del software, donde se establece el dominio de informacin, la funcin, el comportamiento, el rendimiento, las restricciones y los criterios de validacin del software. Tambin se puede ver la estrategia para la prueba del software en el contexto de la espiral: La prueba de unidad , comienza en el vrtice de la espiral y se centra en cada unidad del software, tal como est implementada en cdigo fuente.

La prueba de inte graci n , donde el foco de atencin es el diseo y la construccin de la arquitectura del software. La prueba de validaci n , donde se validan los requisitos del software, comparndolos con el sistema que ha sido construido. El software satisface todos los requisitos funcionales, de comportamiento y de rendimiento. La prueba del sistema , en la que se prueban como un todo el software y otros elementos. Cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total.

1.1.4 Criterios para completar la prueba

"La prueba nunca termina, ya que el responsable del desarrollo del software carga o pasa el problema al cliente" "Se termina la prueba cuando se agota el tiempo o el dinero disponible a tal efecto" Mediante el modelado estadstico y la teora de fiabilidad del software, se pueden desarrollar modelos de fallos del software. Modelo logartmico de Poisson de tiempo de ejecucin: F(t) = (1/p) * ln[(l 0 pt+1)] F(t) es nmero acumulado de fallos que se espera. l0 es la intensidad de fallos inicial del software al principio de la prueba. p es la reduccin exponencial de intensidad de fallo a medida que se encuentran los errores y se van haciendo las correcciones.

1.2

Aspectos estratgicos

Implementar con xito una estrategia de prueba del software: Establecer los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas Establecer los objetivos de la prueba de manera explicita Comprender que usuarios van a manejar el software y desarrollar un perfil para cada categora de usuario Desarrollar un plan de prueba que haga hincapi en la "prueba de ciclo rpido". Construir un software "robusto" diseado para probarse a si mismo. Usar revisiones tcnicas formales efectivas como filtro antes de la prueba. Llevar a cabo revisiones tcnicas formales para evaluar la estrategia de prueba y los propios casos de prueba Desarrollar un enfoque de mejora continua al proceso de prueba. Debera medirse la estrategia de prueba

1.3

Prueba de unidad

La prueba de unidad centra el proceso de verificacin en la menor unidad del diseo del software: el componente software o mdulo.

1.3.1 Consideraciones sobre la prueba de unidad.

1. 2. 3. 4. 5. Se prueba la interfaz del mdulo Se examinan las estructuras de datos locales Se prueban las condiciones lmite Se ejercitan todos los caminos independientes Se prueban todos los caminos de manejo de errores.

Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del mdulo. Se deben disear casos de prueba para detectar errores debidos a clculos incorrectos comparaciones incorrectas o flujos de control inapropiados. La prueba de lmites es la ltima tarea del paso de la prueba de unidad.

1.3.2 Procedimientos de Prueba de unidad

Un controlador no es ms que un "programa principal" que acepta los datos del caso de prueba, pasa estos datos al mdulo e imprime los resultados importantes. Los controladores y resguardos son una sobrecarga de trabajo.

1.4

Prueba de integracin

La prueba de integracin es una tcnica sistemtica para construir una estructura del programa mientras que, al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interaccin. La integracin incremental es la anttesis del enfoque del "big bang". El programa se construye y se prueba en pequeos fragmentos en los que los errores son mas fciles de aislar y corregir, es mas probable que se puedan probar completamente las interfaces y se puede aplicar un enfoque de prueba sistemtica.

1.4.1 Integracin descendente

La prueba de integracin descendente es un planteamiento incremental a la construccin de la estructura de programas. Se integran mdulos movindose hacia abajo por la jerarqua de control, comenzando por el mdulo de control principal (programa principal). La integracin primero-en-profundidad integra todos los mdulos de un camino de control principal de la estructura. La integracin primero-en-anchura incorpora todos los mdulos directamente subordinados a cada nivel, movindose por la estructura de forma horizontal. El proceso de integracin se realiza en una serie de cinco pasos: 1. Se usa el mdulo de control principal como controlador de la prueba, disponiendo de resguardos para todos los mdulos directamente subordinados al mdulo de control principal. 2. Dependiendo del enfoque de integracin se van sustituyendo uno a uno los resguardos subordinados por los mdulos reales. 3. Se llevan a cabo las pruebas cada vez que se integra un nuevo mdulo real 4. Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el mdulo real. 5. Se hace la prueba de regresin para asegurarse de que no se han introducido errores nuevos. En una estructura de programa bien fabricada, la toma de decisiones se da en los niveles superiores de la jerarqua y, por lo tanto, se encuentran errores antes.

1.4.2 Integracin ascendente

Empieza la construccin y la prueba con los mdulos atmicos y se elimina la necesidad de resguardos.

Se puede implementar una estrategia de integracin ascendente mediante los siguientes 4 pasos: 1. Se combinan los mdulos de bajo nivel en grupos que realicen una subfusin especfica del software. 2. Se escribe un controlador para coordinar la entrada y la salida de los casos de prueba. 3. Se prueba el grupo. 4. Se eliminan los controladores y se combinan los grupos movindose hacia arriba por la estructura del programa.

1.4.3 Prueba de regresin

Cada vez que se aade un nuevo modulo como parte de una prueba de integracin, el software cambia. Se establecen nuevos caminos de flujo de datos, pueden ocurrir nuevas E/S y se invoca una nueva lgica de control. La prueba de regresin es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados. La prueba de regresin es la actividad que ayuda a asegurar que los cambios no introducen un comportamiento no deseado o errores adicionales.

1.4.4 Prueba de humo

La prueba de humo es un mtodo de prueba de integracin que es comnmente utilizada cuando se ha desarrollado un producto de software "empaquetado". Actividad es de la prueba de humo: 1. Los componentes software que han sido traducidos a cdigo se integran en una "construccin". Una construccin incluye ficheros de datos, libreras, mdulos reutilizables y componentes de ingeniera que se requieren para implementar una o ms funciones del producto. 2. Se disea una serie de pruebas para descubrir errores que impiden a la construccin realizar su funcin adecuadamente. El objetivo ser descubrir errores "bloqueantes" que tengan mayor probabilidad de impedir al proyecto de software el cumplimiento de su planificacin. 3. Es habitual en la prueba de humo que la construccin se integre con otras construcciones y que se aplique una prueba de humo al producto completo. La integracin pude hacerse bien de forma descendente (top-down) o ascendente (bottom-up).

1.4.5 Comentarios sobre la prueba de integracin

Un modulo crtico es aquel que tiene una o ms de las siguientes caractersticas: Est dirigido a varios requisitos del software Tiene un mayor nivel de control Es complejo o propenso a errores Tiene unos requisitos de rendimiento muy definidos

1.5

Prueba de validacin

La validacin puede definirse de muchas formas, pero una simple definicin es que la validacin se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente, las cuales estn definidas en la Especificacin de Requisitos del Software.

1.5.1 Criterios para la prueba de validacin

Una vez que se procede con cada caso de prueba de validacin, puede darse una de las dos condiciones siguientes: 1. Las caractersticas de funcionamiento o de rendimiento estn de acuerdo con las especificaciones y son aceptables. 2. Se descubre una desviacin de las especificaciones y se crea una lista de deficiencias.

1.5.2 Revisin de la configuracin

La intencin de la revisin es asegurarse de que todos los elementos de la configuracin del software se han desarrollado apropiadamente, se han catalogado y estn suficientemente detallados para soportar la fase de mantenimiento durante el ciclo de vida del software, a veces se denomina auditoria.

1.5.3 Pruebas alfa y beta

Cuando se construye software a medida para un cliente, se llevan a cabo una serie de pruebas de aceptacin para permitir que el cliente valide todos los requisitos. La prueba alfa : se lleva a cabo, por el cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado. La prueba beta : se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. La prueba beta es una aplicacin "en vivo" del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta e informa a intervalos regulares al desarrollador.

1.6

Prueba del sistema

Un problema tpico de la prueba del sistema es la "delegacin de culpabilidad".

1.6.1 Prueba de recuperacin

La prueba de recuperacin es una prueba del sistema que fuerza al fallo del software de muchas formas y verifica que la recuperacin se lleva a cabo apropiadamente.

1.6.2 Prueba de seguridad

La prueba de seguridad intenta verificar que los mecanismos de proteccin incorporados en el sistema lo protegern, de hecho, de accesos impropios. Con el tiempo y recursos suficientes, una buena prueba de seguridad terminar por

acceder al sistema, el objetivo es hacer que el coste de la entrada ilegal sea mayor que el valor de la informacin contenida.

1.6.3 Prueba de resistencia (Stress)

Las pruebas de resistencia estn diseadas para enfrentar a los programas con situaciones anormales. La prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volmenes anormales. Una variante de la prueba de resistencia es una tcnica denominada prueba de sensibilidad. La prueba de sensibilidad intenta descubrir combinaciones de datos dentro de una clase de entrada vlida que pueda producir inestabilidad o un proceso incorrecto.

1.6.4 Prueba de rendimiento

La prueba de rendimiento esta diseada para probar el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado. Las pruebas de rendimiento, a menudo, van emparejadas con las pruebas de resistencia, y frecuentemente, requieren instrumentacin tanto del software como de hardware.

1.7

Fundamentos de las pruebas del software

El ingeniero crea una seria de casos de prueba que intentan "demoler" el software construido. De hecho, las pruebas son uno de los pasos de la ingeniera del software que se puede ver como destructivo en lugar de constructivo.

1.7.1 Objetivo de las pruebas

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

1.7.2 Principios de las pruebas

A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente Las pruebas deberan planificarse mucho antes de que empiecen El principio de Pareto es aplicable a la prueba del software Las pruebas deberan empezar por lo "pequeo" y progresar hacia lo "grande". No son posibles las pruebas exhaustivas Para ser eficaces, las pruebas deberan ser realizadas por un equipo independiente

1.7.3 Facilidad de prueba

La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora. Como la prueba es tan profundamente difcil, merece la pena saber que se puede hacer para hacerlo mas sencillo. Operatividad : cuando mejor funcione, mas eficientemente se puede probar. El sistema tiene pocos errores Ningn error bloquea la ejecucin de las pruebas El producto evoluciona en fases funcionales Observabilidad : lo que se ve es lo que pruebas Se genera una salida distinta para cada entrada Los estados y variables del sistema estn visibles o se pueden consultar durante la ejecucin Los estados y variables anteriores del sistema estn visibles o se pueden consultar Todos los factores que afectan a los resultados estn visibles Un resultado incorrecto se identifica fcilmente Los errores internos se detectan automticamente a travs de mecanismos de auto-comprobacin El cdigo fuente es accesible Controlabilidad : cuando mejor podamos controlar el software, mas se puede automatizar y optimizar Todos los resultados posibles se pueden generar a travs de alguna combinacin de entrada Todo el cdigo es ejecutable a travs de alguna combinacin de entrada El ingeniero de pruebas puede controlar directamente los estados y las variables del hardware y del software Los formatos de las entradas y los resultados son consistentes y estructurados Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente. Capacidad de descomposici n: controlando el mbito de las pruebas, podemos aislar ms rpidamente los problemas y llevar a cabo mejores pruebas de regresin. El sistema de software est construido con mdulos independientes Los mdulos del software se pueden probar independientemente Simplicidad : cuando menos haya que probar, mas rpidamente podremos probarlo Simplicidad funcional Simplicidad estructural Simplicidad de cdigo Estabilidad : cuanto menos cambios, menos interrupciones a las pruebas Los cambios del software son infrecuentes Los cambios del software estn controlados Los cambios del software no invalidan las pruebas existentes El software se recupera bien de los fallos Facilidad de comprensi n: cuanta mas informacin tengamos, mas inteligentes sern las pruebas. El diseo se ha entendido perfectamente Las dependencias entre los componentes internos, externos y compartidos se han entendido perfectamente Se han comunicado los cambios del diseo La documentacin tcnica es instantneamente accesible La documentacin tcnica esta bien organizada La documentacin tcnica es especifica y detallada La documentacin tcnica es exacta

Atributos de una "buena" prueba: 1. Una buena prueba tiene una alta probabilidad de encontrar un error 2. Una buena prueba no debe ser redundante. El tiempo y los recursos para las pruebas son limitados 3. Una buena prueba debera ser "la mejor de la cosecha" 4. Una buena prueba no debera ser ni demasiado sencilla, ni demasiado compleja. En general, cada prueba debera realizarse separadamente

1.8

Diseo de casos de prueba

El producto debe probarse de 2 formas: conociendo la funcione especfica para la que fue diseado el producto. La prueba de "Caja Negra" se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. Los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se aceptar de forma adecuada y que se produce un resultado correcto, as como que la integridad de la informacin externa se mantiene Conociendo el funcionamiento del producto. La prueba de Caja Blanca (funcin) se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lgicos del software proponiendo casos de prueba que ejerciten conjuntos especficos de condiciones y/o bucles. Se puede examinar el "estado del programa" en varios puntos para determinar si el estado real coincide con el esperado o mencionado.

1.9

Prueba de Caja Blanca

Es un mtodo de diseo de casos de prueba que usa la estructura de control del diseo procedimental para obtener los casos de prueba: 1. Que garanticen que se ejercita por lo menos una vez todos los caminos independientes de cada mdulo 2. Que se ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa 3. Que se ejecuten todos los bucles en sus lmites y con sus lmites operacionales 4. Que se ejerciten las estructuras internas de datos para asegurar su validez

1.10 Prueba del Camino Bsico

La prueba del camino bsico es una tcnica de prueba de caja blanca. El mtodo del camino bsico permite al diseador de casos de prueba obtener una medida de la complejidad lgica de un diseo procedimental y usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Los casos de prueba obtenidos del conjunto bsico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del problema.

1.10.1

Notacin del grafo de flujo

El grafo de flujo representa el flujo de control lgico mediante la siguiente notacin:

Cada crculo, denominado nodo del grafo de flujo, representa una o mas sentencias procedimentales. Las flechas del grafo de flujo, denominadas aristas enlaces, representan flujo de control y son anlogas a las flechas del diagrama de flujo. Las reas delimitadas por aristas y nodos se denominan regiones. Cuando contabilizamos las regiones incluimos el rea exterior del grafo, contando como otra regin ms. Cada nodo que contiene una condicin se denomina nodo predicado y est caracterizado porque dos o ms aristas emergen de l.

1.10.2

Complejidad ciclomtica

La complejidad ciclomtica es una mtrica del software que proporciona una medicin cuantitativa de la complejidad lgica de un programa. El valor calculado como complejidad ciclomtica define el numero de Caminos Independientes del conjunto bsico de un programa y nos da un lmite superior para el nmero de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez. Un camino independiente es cualquier camino del programa que introduce, por lo menos, un nuevo conjunto de sentencias de proceso o una nueva condicin. La complejidad se puede calcular de 3 formas: 1. El nmero de regiones del grafo coincide con la complejidad ciclomtica 2. La complejidad ciclomtica, V(G), de un grafo de flujo G se define como: a. V(G) = A - N + 2 (donde N son los nodos y A las reas) 3. La complejidad ciclomtica, V(G), de un grafo de flujo G se tambin define como: a. V(G) = P + 1 (donde P son los nodos predicados)

1.10.3

Obtencin de casos de pruebas

El mtodo de prueba de camino bsico se puede aplicar a un diseo procedimental detallado o a un cdigo fuente. En esta seccin, presentaremos la prueba del camino bsico como una serie de pasos: 1. Usando el diseo o el cdigo como base, dibujamos el correspondiente grafo de flujo 2. Determinamos la complejidad ciclomtica del grafo de flujo correspondiente 3. Determinamos un conjunto bsico de caminos linealmente independientes 4. Preparamos los casos de prueba que forzarn la ejecucin de cada camino del conjunto bsico

Es importante darse cuenta de que algunos caminos independientes no se pueden probar de forma aislada.

1.10.4

Matrices de grafos

Una matriz de grafo es una matriz cuadrada cuyo tamao es igual al nmero de nodos del grafo de flujo. Cada fila y cada columna corresponde a un nodo especfico y las entradas de la matriz corresponden a las conexiones entre los nodos. Aadiendo un peso al enlace a cada entrada de la matriz, la matriz de grafo se puede convertir en una potente herramienta para la evaluacin de la estructura de control de programa durante la prueba. En su forma ms sencilla, el peso de enlace es 1 0. Otras propiedades ms interesantes: La probabilidad de que un enlace sea ejecutado El tiempo de procesamiento asociado al recorrido de un enlace La memoria requerida durante el recorrido de un enlace Los recursos requeridos durante el recorrido de un enlace.

1.11 Prueba de la estructura de control

La tcnica de prueba del camino bsico es una de las muchas tcnicas para la prueba de la estructura de control.

1.11.1

Prueba de condicin

La prueba de condicin es un mtodo de diseo de casos de prueba que ejercita las condiciones lgicas contenidas en el mdulo de un programa. A una condicin sin expresiones relacionadas se al denomina Expresin lgica. Si una condicin es incorrecta, entonces es incorrecto al menos un componente de la condicin. As, los tipos de errores de una condicin pueden ser los siguientes: Error en operador lgico Error en parntesis lgico Error en operador relacional Error en expresin aritmtica El mtodo de la prueba de condiciones se centra en la prueba de cada una de las condiciones del programa. Las estrategias de prueba de condiciones tienen, generalmente, dos ventajas: 1. La cobertura de la prueba de una condicin es sencilla 2. La cobertura de la prueba de las condiciones de un programa da una orientacin para generar pruebas adicionales del programa Estrategias de prueba de condiciones: 1. La prueba de ramificaciones 2. La prueba del dominio 3. BRO (prueba del operador relacional y de ramificaciones): garantiza la deteccin de errores de operadores relacionales y de ramificaciones en una condicin dada, en la que todas las variables lgicas y operadores relacionales de la condicin aparecen slo una vez y no tienen variables en comn.

1.11.2

Prueba de flujo de datos

El mtodo de prueba de flujo de datos selecciona caminos de prueba de un programa de acuerdo con la ubicacin de las definiciones y los usos de las variables del programa. Para una sentencia con S como nmero de sentencia: DEF(S) = {X | la sentencia S contiene una definicin de X} USO(S) = {X | la sentencia S contiene un uso de X}

1.11.3

Prueba de bucles

La prueba de bucles es una tcnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles: Bucles simples Bucles concatenados Bucles anidados Bucles no estructurados

Bucles simples : a los bucles simples se les debe aplicar el siguiente conjunto de pruebas, donde n es el nmero mximo de pasos permitidos por el bucle: 1. pasar por alto totalmente el bucle 2. pasar una sola vez por el bucle 3. pasar 2 veces por el bucle 4. hacer m pasos por el bucle con m < n 5. hacer n - 1 , n y n + 1 pasos por el bucle Bucles anidados: 1. Comenzar por el bucle ms interior. Establecer o configurar los dems bucles con sus valores mnimos. 2. Llevar a cabo las pruebas de bucles simples para el bucle ms interior, mientras se mantienen los parmetros de iteracin de los bucles externos en sus valores mnimos. Aadir otras pruebas para valores fuera de rango o excluidos. 3. Progresar hacia fuera, llevando a cabo pruebas para el siguiente bucle, pero manteniendo todos los bucles externos en sus valores mnimos y los dems bucles anidados en sus valores "tpicos" 4. Continuar hasta que se hayan probado todos los bucles Bucles concatenados : Los bucles concatenados se pueden probar mediante el enfoque anteriormente definido para bucles simples. Bucles no estructurados: se deben redisear para que se ajusten a las construcciones de programacin estructurada.

1.12 Prueba de Caja Negra

Las pruebas de caja negra, tambin denominadas prueba de comportamiento, se centran en los requisitos funcionales del software. Permite al ingeniero del software obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. La prueba de caja negra intenta encontrar errores de las siguientes categoras: 1. Funciones incorrectas o ausentes 2. Errores de interfaz 3. Errores en estructuras de datos o en accesos a base de datos externas 4. Errores de rendimiento 5. Errores de inicializacin y terminacin Tiende a aplicarse durante las fases posteriores de la prueba, ya que la prueba de caja negra ignora intencionalmente la estructura de control, centra su atencin en el campo de la informacin Casos de prueba: 1. Casos de prueba que reducen, en un coeficiente que es mayor que uno, el nmero de casos de prueba adicionales que se deben disear para alcanzar una prueba razonable. 2. Casos de prueba que nos dicen algo sobre la presencia o ausencia de clases de errores en lugar de errores asociados solamente con la prueba que estamos realizando.

1.12.1

Mtodos de prueba basados en grafos

Modelado del flujo de transaccin Modelado de estado finito Modelado del flujo de datos Modelado de planificacin

Las pruebas basadas en grafos empiezan con la definicin de todos los nodos y peso de nodos. Una vez que se han identificado los nodos, se deberan establecer los enlaces y los pesos de enlaces. Cada relacin es estudiada separadamente, de manera que se puedan obtener casos de prueba.

1.12.2

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. Una clase de equivalencia representa un conjunto de estados vlidos o no vlidos para condiciones de entrada. Las clases de equivalencia se pueden definir segn: 1. Se una condicin de entrada especifica un rango, se define una clase de equivalencia vlida y dos no vlidas. 2. Si una condicin de entrada requiere un valor especfico, se define una clase de equivalencia vlida y dos no vlidas. 3. Si una condicin de entrada especifica un miembro de un conjunto, se define una clase de equivalencia vlida y una no vlida. 4. Si una condicin de entrada es lgica, se define una clase de equivalencia vlida y una no vlida.

1.12.3

Anlisis de valores lmite

El anlisis de valores lmite es una tcnica de diseo de casos de prueba que complementa a la particin equivalente.

1.12.4

Prueba de comparacin

Hay situaciones en las que la fiabilidad del software es algo absolutamente crtico. En este tipo de aplicaciones, a menudo se utiliza hardware y software redundante para minimizar la posibilidad de error. Cuando se han producido mltiples implementaciones de la misma especificacin, a cada versin del software se le proporciona como entrada los casos de prueba diseados mediante alguna otra tcnica de caja negra.

1.12.5

Prueba de la tabla ortogonal

La prueba de la tabla ortogonal puede aplicarse a problemas en que el dominio de entrada es relativamente pequeo pero demasiado grande para posibilitar pruebas exhaustivas. Es til al encontrar errores asociados con fallos localizados. La tabla ortogonal L9 tiene un "propiedad de equilibrio". Es decir, los casos de prueba estn "uniformemente dispersos en el dominio de prueba".

1.13 Prueba de Entornos Especializados, Arquitecturas y Aplicaciones

1.13.1 Prueba de interfaces grficas de usuario (IGUs)

Los grafos de modelado de estado finito pueden ser utilizados para realizar pruebas que vayan dirigidas sobre datos especficos y programas objeto que sean relevantes para las IGUs.

1.13.2 1.13.3

Pruebas de arquitectura cliente / servidor Pruebas de la documentacin y facilidades de ayuda

Los errores en la documentacin pueden ser tan destructivos para la aceptacin del programa, como los errores en los datos o en el cdigo fuente

1.13.4

Prueba de sistemas de tiempo-real

Estrategia de 4 pasos: 1. Prueba de tareas : el primer paso de la prueba de sistemas de tiempo real consiste en probar cada tarea independientemente. 2. Pruebas de comportamiento : utilizando modelos del sistema creados con herramientas CASE, es posible simular el comportamiento del sistema en tiempo real y examinar su comportamiento como consecuencia de sucesos externos. 3. Prueba intertareas : una vez que se han aislado los errores en las tareas individuales y en el comportamiento del sistema, la prueba se dirige hacia los errores relativos al tiempo. 4. Prueba del sistema : el software y el hardware estn integrados, por lo que se lleva a cabo una serie de pruebas completas del sistema para intentar descubrir errores en la interfaz software / hardware.

2 2.1

Pruebas orientadas a objetos. Ampliando la visin de las pruebas

Una mala interpretacin de la definicin de la clase puede conducir a relaciones de clases incorrectas o irrelevantes. Durante las etapas finales de su desarrollo, los modelos de AOO y de DOO proporcionan informacin substancial acerca de la estructura y comportamiento del sistema. Todos los modelos orientados a objetos deben ser probados, para asegurar la exactitud, compresin y consistencia, dentro de la sintaxis, semntica y pragmtica del modelo.

2.2

Pruebas de los Modelos de AOO y DOO

2.2.1 Exactitud de los modelos AOO y DOO

La exactitud sintctica se juzga en el uso apropiado de las simbologas; cada modelo se revisa para asegurarse de que se han mantenido las convenciones propias del modelo. Las relaciones entre clases (conexiones de instancia) se evalan para determinar si reflejan con exactitud conexiones del mundo real.

2.2.2 Consistencia de los modelos AOO y DOO

Debe juzgarse "considerando las relaciones entre entidades dentro del modelo". Para evaluar la consistencia, se debe examinar cada clase y sus conexiones a otras clases. Un modelo clase-responsabilidad-colaboracin (CRC), y un diagrama objeto-relacin pueden utilizarse para facilitar esta actividad. Cada tarjeta CRC muestra el nombre de la clase, sus responsabilidades (operaciones) y sus colaboradores (otras clases a las que se envan mensajes y de las cuales depende para el cumplimiento de sus responsabilidades) El modelo de objeto-relacin proporciona una representacin grfica de las conexiones entre clases. Toda esta informacin se puede obtener del modelo de AOO. Para evaluar el modelo de clases, se recomienda los siguientes pasos: 1. Revisar el modelo CRC y el modelo objeto-relacin. Realizar un control cruzado, para asegurarse de que todas las colaboraciones implicadas en el modelo AOO hayan sido representadas adecuadamente. 2. Inspeccionar la descripcin de cada tarjeta CRC, para determinar si alguna responsabilidad delegada es parte de la definicin del colaborador. 3. Invertir la conexin para asegurarse de que colaborador que solicita un servicio recibe las peticiones de una fuente razonable. 4. Utilizando las conexiones invertidas, ya examinadas en el paso 3, determinar si otras clases se requieren y si las responsabilidades se han repartido adecuadamente entre las clases. 5. Determine si las responsabilidades muy solicitadas, deben combinarse en una sola responsabilidad.

6. Se aplican iterativamente los pasos 1 a 5 para cada clase y durante cada evolucin del modelo de AOO.

2.3

Estrategias de Prueba Orientadas a Objetos

2.3.1 Las pruebas de unidad en el contexto de la OO

En vez de probar un mdulo individual, la unidad mas pequea comprobable es la clase u objeto encapsulado. No se puede probar mas de una operacin a la vez, pero si como parte de una clase. La prueba de clases para el software OO se conduce mediante operaciones encapsuladas por la clase y el comportamiento de la clase.

2.3.2 Las pruebas de integracin en el contexto OO

Las pruebas basadas en hilos , se integran el conjunto de clases requeridas, para responder una entrada o suceso al sistema. Cada hilo se integra y prueba individualmente. Las pruebas de regresin se aplican para asegurar que no ocurran efectos colaterales. La prueba basada en el uso , comienza la construccin del sistema probando aquellas clases, que utilizan muy pocas clases servidoras. Despus de que las clases independientes se prueban, esta secuencia de prueba por capas de clases dependientes contina hasta que se construye el sistema completo. La prueba de agrupamiento es una fase en las pruebas de integracin de software OO. Aqu, un agrupamiento de clases colaboradores se prueban diseando los casos de prueba, que intenta relevar errores en las colaboraciones.

2.3.3 Pruebas de validacin en un contexto OO

Los casos de uso proporcionan un escenario, que tiene una gran similitud de errores con los relevados en los requisitos de interaccin del usuario. Los mtodos de prueba convencionales de caja negra pueden usarse para realizar pruebas de validacin.

2.4

Diseo de Casos de Prueba para software OO

1. Cada caso de prueba debe ser identificado separadamente, y explcitamente asociado con la clase a probar. 2. Debe declararse el propsito de la prueba 3. Debe desarrollarse un alista de pasos a seguir, como consecuencia de la prueba, pero adems debe contener: a. Definicin de una lista de estados, especficos para el objeto a probar b. Una lista de mensajes y operaciones, que se ejercitarn como consecuencia de las pruebas c. Una lista de excepciones, que pueden ocurrir conforme el objeto se comprueba d. Una lista de condiciones externas e. Informacin adicional

La prueba OO se enfoca en las secuencias de operaciones de diseo apropiadas para probar los estados de una clase.

2.4.1 Implicaciones de los conceptos de OO al diseo de casos de prueba

La clase es el objetivo del diseo de casos de prueba. La encapsulacin puede dificultar un poco la obtencin de esta informacin. La herencia tambin conduce a retos adicionales para el diseador de casos de prueba.

2.4.2 Aplicabilidad de los mtodos convencionales de diseo de casos de prueba

Los mtodos de "caja blanca" pueden aplicarse a las operaciones definidas para una clase. Los mtodos de prueba de "caja negra" son tan apropiados para los sistemas OO, como los son para los sistemas desarrollados utilizando mtodos convencionales de ingeniera del software.

2.4.3 Pruebas basadas en errores

Disear pruebas que tengan una alta probabilidad de revelar fallos. Las pruebas de integracin buscan fallos probables en operaciones o mensajes de conexin. Hay 3 tipos de fallos en este contexto: Resultados inesperados Uso incorrecto de operaciones / mensajes Invocaciones incorrectas Las pruebas de integracin se aplican tanto a atributos como a operaciones.

2.4.4 El impacto de la programacin OO en las pruebas

Cuando se invoca una operacin es difcil decir exactamente que cdigo se ejecuta. Probar las operaciones de clases es anlogo a probar cdigo que toma a un parmetro de la funcin y luego la invoca. Los errores de integracin se vuelven ms probables.

2.4.5 Casos de prueba y jerarqua de clases

Las entradas de las pruebas deben ser apropiadas para las clases base y derivada, pero los resultados esperados pueden diferir en la clase derivada.

2.4.6 Diseo de pruebas basadas en el escenario

Cuando ocurren errores asociados con especificaciones errneas, el producto no realiza lo que el cliente desea. Los errores asociados con la interaccin de subsistemas ocurren cuando el comportamiento de un subsistema crea circunstancias que causan que el otro subsistema falle. Las pruebas basadas en el escenario se concentran en lo que el usuario hace. Los escenarios revelan errores de iteracin. Las pruebas basadas en el escenario tienden a validar subsistemas en una prueba

sencilla.

2.4.7 Las estructuras de pruebas superficiales y profundas

La estructura superficial se refiere a la estructura visible al exterior de un programa OO. Esto es, la estructura que es inmediatamente obvia al usuario final. En una interfaz basada en objetos, el verificador debe usar la lista de todos los objetos, como una lista de control de pruebas. El diseo de representaciones de jerarquas de clases proporciona una visin de la estructura de herencia. La estructura jerrquica se utiliza en la verificacin basada en errores.

2.5

Mtodos de Prueba aplicables a nivel de Clases

La prueba "en pequeo", se enfoca en una sola clase y los mtodos encapsulados por ella. La verificacin y particin al azar son mtodos que pueden usarse para ejercitar a una clase durante la prueba OO.

2.5.1 La verificacin al azar para clases OO 2.5.2 Prueba de particin al nivel de clases
Las entradas y salidas se clasifican, y los casos de prueba se disean, para validar cada categora. La particin basada en estados clasifica las operaciones de clase basada en su habilidad de cambiar el estado de la clase. La particin basada en atributos clasifica las operaciones de la clase en los atributos que ellas usan. La particin basada en categoras clasifica las operaciones de la clase basadas en la funcin genrica que cada una lleva a cabo.

Las operaciones se dividen en 3 particiones: 1. Operaciones que utilizan (atributo) 2. Operaciones que modifican (atributo) 3. Operaciones que no utilizan o modifican (atributo)

2.6

Diseo de Casos de prueba Interclase

El diseo de casos de prueba se vuelve mas complicado cuando la integracin del sistema OO comienza.

2.6.1 Prueba de mltiples clases

Generar casos de prueba aleatorios para mltiples clases: 1. Para cada clase cliente, utilice la lista de operaciones de clase, para generar una serie de secuencias de pruebas al azar 2. Para cada mensaje que se genere, determine la clase colaboradora y la operacin correspondiente en el objeto servidor 3. Para cada operacin en el objeto servidor (invocada por mensajes enviados por el objeto cliente), determinar los mensajes que transmite 4. Para cada uno de los mensajes, determine el siguiente nivel de operaciones que son invocadas, e incorpore stas a la secuencia de pruebas.

2.6.2 Prueba derivada de los modelos de comportamiento

El DTE (diagrama de transicin de estados) para una clase puede usarse para ayudar a derivar una secuencia de pruebas, que ejercitarn el comportamiento dinmico de la clase. Las pruebas a disearse deben alcanzar una cobertura de todos los estados. El modelo de estados puede ser recorrido "primero a lo ancho". En este contexto, primero a lo ancho implica que un caso de prueba valida una sola transicin y despus, cuando se va a verificar una nueva transicin, se utilizan slo las transiciones previamente verificadas.

Pruebas de entornos especializados.

Patrones de prueba.

Documentacin de pruebas.

Como en toda fase, todos los elementos preparados para las pruebas y los resultados de las mismas deben ser documentados y adjuntados a cada versin correspondiente de los productos de las fases anteriores. Esta forma de proceder evitar la repeticin de pruebas y facilitar la preparacin de nuevas pruebas a partir de otras anteriores.

5.1

Plan de pruebas

Son un conjunto de actividades que pretenden demostrar que el producto cumple con lo estipulado en el contrato. En el plan de pruebas se especifica: Identificador del plan: debera ser una palabra que lo identificase con su alcance. Debe incluir adems la versin y fecha. Alcance: tipo de prueba y propiedades del software a ser probado. Items a probar: configuracin a probar y condiciones que se deben satisfacer para ello. Estrategia: tcnica y herramientas que se van a utilizar. Hay que indicar el nmero mnimo de casos de prueba que se van a realizar y el grado de automatizacin tanto en la generacin de casos de prueba como en la ejecucin Categorizacin de la configuracin: condiciones bajo las cuales el plan debe ser:

Suspendido: Si se presentan demasiados defectos o fallos. Repetido. Dador por terminado. Si se cumple el nmero mnimo de casos de prueba. Documentacin: Segn el estndar IEEE 829-1983 hay que producir los siguientes documentos: o Plan de prueba. o Especificacin de los requerimientos para el diseo de los casos de prueba. o Casos de prueba. Para cada uno se especifican: el procedimiento de prueba y descripcin del tem a probar. o Bitcoras de pruebas. o Informe de incidentes de prueba. o Resumen de pruebas. Procedimientos especiales: grafo de las tareas necesarias para preparar y ejecutar las pruebas, as como habilidades necesarias. Recursos: pueden ser muy variados o Caractersticas de hardware y software. o Software necesario para hacer las pruebas. o El software bajo prueba. o Configuracin del software de apoyo. o Recursos humanos necesarios para el proceso. o Requerimientos especiales: actualizacin de licencias, espacio de oficina, tiempo de mquina, seguridad, etc. Calendario: hitos del proceso y grafo de dependencias. Riesgos: riesgos del plan, acciones para mitigarlos y planes de contingencia. Responsables: lista de personas y tareas asignadas. Existen cuatro tipos de pruebas que deben superarse o Pruebas funcionales: se realizan con los datos de entrada normales en el uso diario del sistema. Se comprueban sobre todo valores en los lmites de las variables y un poco ms all de los lmites. Tambin algunos valores especiales. o Pruebas de desempeo: miden el rendimiento del sistema: tiempos de respuesta, utilizacin de la memoria, trfico generado en las comunicaciones, etc. Estas pruebas nos van a indicar dnde estn los cuellos de botella del sistema. o Pruebas de tensin: se trata de sobrepasar los lmites de tolerancia del sistema de varias maneras, por ejemplo: conectar ms usuarios al sistema de los permitidos, si se tienen que gestionar x mega-bits por segundo de una lnea de comunicaciones probar a aumentar a x + 1, etc. o Pruebas estructurales: es un anlisis de la lgica interna de un programa. o o o