Anda di halaman 1dari 19

Estrategias de Prueba del Software Captulo 17 Integra los mtodos de diseo de caso de pruebas del software en una serie

e bien planeada de pasos que desembocar en la eficaz construccin del software. Cualquier estrategia de prueba debe incorporar la planeacin de las pruebas y la recoleccin y evaluacin de los datos resultantes. Vistazo Rpido El software se prueba para descubrir errores cometidos al realizar el diseo y construccin. Quin lo hace? El jefe de proyecto, los ingenieros y/o los especialistas en pruebas son quienes desarrollan la estrategia a seguir.

Las pruebas requieren una gran cantidad de esfuerzo si se realizan sin un plan, se desperdicia el tiempo y es posible no encontrar errores.

Un enfoque estratgico para la prueba del software Se debe definir una plantilla para las pruebas del software. Para realizar pruebas efectivas un equipo debe efectuar revisiones tcnicas formales y efectivas. Se comienza a nivel de componentes y trabaja hacia afuera hasta integrar todo. Diferentes tipos de prueba son apropiadas en diferentes momentos. La prueba es dirigida por el desarrollador de software o por un grupo independiente de pruebas si el proyecto es grande.

La prueba y la depuracin son actividades diferentes, pero la segunda debe incluirse en cualquier estrategia de prueba. Las pruebas deben ser de bajo nivel (para confirmar la correcta implementacin de un pequeo segmento de cdigo) y de alto nivel (para validar las funciones principales)

Verificacin y validacin Verificacin es el conjunto de actividades que aseguran que el software implemente correctamente una funcin especifica, Validacin es un conjunto diferente de actividades que aseguran que el software construido corresponde con los requisitos del cliente. Verificacin: construimos el producto correctamente.

Validacin: construimos el producto correcto.

Organizacin para las pruebas Las pruebas son el ultimo esfuerzo para la evaluacin de la calidad y de descubrimiento de errores. El papel del grupo independiente de prueba consiste en eliminar los problemas propios de dejar que el constructor pruebe lo que el mismo ha construido. Sin embargo el ingeniero no debe alejarse, deben trabajar unidos. Criterios para completar la prueba Nunca se termina de aplicar una prueba. Algunas terminan cuando se agota el tiempo o el dinero. No se puede asegurar que un software nunca va a fallar.

Aspectos estratgicos. Se deben especificar los requisitos del producto de manera cuantificable mucho antes de que empiecen las pruebas. Se deben establecer explcitamente los objetivos de la prueba. Se debe comprender cuales son los usuarios del software y desarrollar un perfil para cada categora de usuario. Construir un software robusto diseado para probarse a si mismo, y capazas de diagnosticar ciertos tipos de error. Usar revisiones tcnicas formales y efectivas como filtro previo a la prueba. Realizar revisiones tcnicas formales para evaluar la

estrategia de prueba y los propios casos de prueba. Desarrollar un enfoque de mejora continua para el proceso de prueba. Estrategias de prueba para el software convencional. Un esquema puede ser esperar hasta que el producto est totalmente construido y luego aplicar pruebas al sistema general esperando encontrar errores. Aunque parece muy atractivo simplemente no funciona. Arrojar un software plagado de errores, molesto para el cliente y el usuario final. Por otra parte un ingeniero podra aplicar pruebas diariamente, sin importar la parte del sistema que se construya.

Aunque no es tan atractivo es muy efectivo. Por lo general se busca un intermedio entre esos dos extremos. Se puede dividir en clases. Pruebas de Unidad Se concentra en el esfuerzo de verificacin de la unidad mas pequea del diseo del software. Centradas en la lgica del procesamiento interno y en las estructuras de datos dentro de los lmites de un componente. Prueba de integracin Es una tcnica para construir la arquitectura del software mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados a la interfaz

El objetivo es tomar componentes a los que se aplic una prueba de unidad y construir una estructura de programa que determine el diseo. Pruebas de Validacin Empiezan tras la culminacin de las pruebas de integracin, despus de evaluar cada componente y ya se ha terminado de ensamblar el software como paquete. La validacin se logra mediante una serie de pruebas que demuestran que se cumple con los requisitos. Revisin de la configuracin Su objetivo es asegurar que todos los elementos de la configuracin del software se hayan desarrollado apropiadamente, estn

catalogados y tengan el detalle suficiente para reforzar la fase de soporte del ciclo de vida del software. Pruebas alfa y beta No se sabe con certeza como utilizar el usuario final el software. La prueba alfa la aplican los usuarios finales en el lugar de trabajo del desarrollador. Las pruebas beta se aplican en el lugar de trabajo de los usuarios finales. A diferencia de las alfa en las beta el programador no siempre estar presente, si el usuario final encuentra un problema (real o imaginario) se notifica al programador. Prueba del Sistema

Abarcan una serie de pruebas diferentes cuyo propsito principal es ejercitar profundamente el sistema de computo. Pruebas de recuperacin. Pruebas de seguridad. Pruebas de resistencia. Pruebas de desempeo. (en tiempo real)

El arte de la depuracin Ocurre cuando se realiza una prueba con xito, es decir cuando se descubre un error. Surgen 2 opciones, encontrar y depurar la causa del problema, o no localizar el error, se deben disear mas casos de prueba que ayuden a detectar y corregir el error. Tcticas de depuracin Fuerza bruta.

Rastreo hacia atrs: a partir del error se recorre hacia atrs el cdigo fuente (manualmente) hasta hallar la causa. Eliminacin de causas: se elabora una hiptesis y se van descartando causas. Depuradores automatizados: compiladores de depuracin que trazan el camino.

Correccin del error Cuando se encuentra un error debe corregirse, pero se debe tener cuidado, esto puede implicar otros daos. Tcnicas de Prueba del Software Captulo 18 Vistazo Rpido

Una vez generado el cdigo fuente, es necesario probar el software para descubrir (y corregir) la mayor cantidad de errores posible antes de entregarlo al cliente. Aqu entran las tcnicas de prueba, para comprobar la lgica y el comportamiento.

Fundamentos de las pruebas del software Al disear un producto se debe pensar en la facilidad de prueba, Y debe contar con las siguientes caractersticas: Operatividad: cuanto mejor funcione, mejor podr probarse. Observabilidad: lo que se ve es lo que se prueba.

Controlabilidad: cuanto mejor se controle el software mejor se automatizaran y mejoraran las pruebas. Capacidad de descomponer: delimitar la prueba asla problemas ms rpidamente. Simplicidad: cuanto menos hay que probar ms rpido se har. Estabilidad: menos cambios, menores alteraciones a las pruebas. Facilidad de compresin: a mayor informacin, mayor inteligencia se aplicar a la prueba.

Caractersticas de la Prueba Una buena prueba tiene elevada probabilidad de encontrar un error. Una buena prueba no es redundante.

Una buena prueba debe ser la mejor de su clase. Una buena prueba no debe ser muy simple ni demasiado compleja. Pruebas de Caja Negra y Caja Blanca Las pruebas de caja negra se aplican a la interfaz, examina la funcionalidad del software. Las pruebas caja blanca se aplican a la parte procedimental del software y la colaboracin entre componentes. Pruebas caja Blanca. Garantiza todas las rutas independientes dentro del modulo. Ejercitan los lados falso y verdadero de todas las decisiones lgicas.

Ejecutan todos los bucles en sus limites. Ejercitan estructuras de datos internos.

Prueba de Ruta Permite al diseador obtener una medida de complejidad lgica. Se debe demostrar que se ejecuta cada instruccin del programa por lo menos una vez durante la prueba. Pruebas de la estructura de control Prueba de condicin: ejercita las condiciones lgicas contenidas en un modulo del programa. Prueba del flujo de datos: selecciona rutas de prueba de un programa de acuerdo con las ubicaciones de las definiciones y los usos de las variables en el programa. Lo que busca esta

prueba es demostrar que una instruccin no modifique las variables de otra.

Pruebas de bucles: Se concentra en la validez de la construccin de los bucles. Analiza bucles simples, concatenados, anidados, estructurados.

Pruebas de Caja Negra Pueden encontrar errores como: Funciones incorrectas o faltantes. Errores de interfaz. Errores en estructuras de datos o acceso a bases de datos externas. Errores de comportamiento o desempeo. Errores de inicializacin y trmino. Mtodos grficos de prueba: se deben comprender los objetos y las relaciones entre ellos, se

crea una grafica de los objetos y relaciones y se crean pruebas que cubran la grafica. Particin equivalente: divide el dominio de entrada de un programa en clases de datos a partir de las cuales pueden derivarse casos de prueba. Anlisis de valores lmite: se crean casos de prueba con valores lmite. Prueba de tabla ortogonal: se aplica en problemas en los cuales el dominio de entrada es pequeo, pero demasiado grande para una prueba exhaustiva. Prueba basada en fallas: encuentra errores de especificaciones incorrectas e iteraciones entre subsistemas Prueba basada en escenarios: se concentra en lo que hace el usuario, no en el producto

Mtodos de prueba aplicables al nivel de clase Prueba aleatoria para clases: realizar una tarea por distintos caminos. Prueba de particin al nivel de clase: probar interfaces por separado. Prueba de entornos especializados Prueba de interfaz grfica de usuario. Prueba de arquitectura cliente servidor. Prueba de la documentacin y las funciones de ayuda. Prueba de sistemas en tiempo real.
Prueba de tareas. Pruebas de comportamiento. Prueba intertareas. Prueba del sistema.

Patrn de prueba. No solo proporcionan una directriz til, sino que tambin dan beneficios adicionales: Proporcionan una terminologa en los encargados de problemas. Concentran la atencin de las fuerzas detrs del problema Estimulan al razonamiento iterativo.

Anda mungkin juga menyukai