Você está na página 1de 7

Universidad Tecnolgica Costarricense

II Cuatrimestre 2011

Ingeniera en Sistemas Curso: Ingeniera de Software Alumno Jorge Morera Montero

Octubre, 2011
Estrategias de pruebas del software Una estrategia de prueba, proporciona la adecuada planeacin para una correcta aplicacin de las pruebas que fueron diseadas. Se trata de una gua lo suficientemente flexible para promover la creatividad y la adaptabilidad necesarias para adecuar las pruebas al entorno y la arquitectura del software aprobar.

Esta estrategia proporciona un mapa donde se describen los pasos que se darn como parte de la prueba, indica cundo se planean, cundo se dan los pasos, cunto esfuerzo, tiempo y recursos se consumen en el enfoque estratgico para la prueba del sw. Las pruebas son el punto culminante de un proceso de calidad y comenz desde el anlisis y son el punto en el cual se trata de asegurar la calidad del software, razn por la cual es una actividad de suma importancia. Una planilla para la prueba del software: Es un conjunto de pasos en los que se puede situar los mtodos de diseo de casos de prueba. Planilla, caractersticas generales: La prueba comienza en el nivel de modulo y trabaja hacia fuera, hacia la integracin de todo el sistema b asado en computadora. Dependiendo del momento asi ser la prueba adecuada. La prueba la lleva a cabo el responsable del desarrollo del software y para proyectos mas grandes o de mayor trabajo la prueba la realiza un grupo independiente. La prueba y la depuracin son actividades diferentes, pero en la depuracin se debe incluir estrategia de prueba. Una estrategia debe proporcionar una gua al profesional. En muchos aspectos, la prueba es un proceso individualista y el nmero de tipos diferentes de pruebas vara tanto como los diferentes enfoques de desarrollo. Durante muchos aos, nuestra nica defensa contra los errores de programacin era un cuidadoso diseo y la propia inteligencia del programador. Ahora nos encontramos en una era en la que las tcnicas modernas de diseo (y las revisiones tcnicas formales) nos ayudan a reducir el nmero de errores iniciales que se encuentran en el cdigo de forma inherente. De forma similar, los diferentes mtodos de prueba estn empezando a agruparse en varias filosofas y enfoques diferentes. Organizacin para la prueba del software El proceso de ingeniera del software se puede ver como una espiral, como inicialmente, la ingeniera del sistema 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. Si consideramos el proceso desde el punto de vista procedimental, la prueba, en el contexto de la ingeniera del software, realmente es una serie de cuatro pasos que se llevan a cabo secuencialmente: prueba de unidad la prueba de integracin prueba de alto nivel la prueba de validacin Para realizar pruebas efectivas un equipo de sw debe efectuar revisiones tcnicas formales y efectivas, la prueba comienza al nivel de componentes y trabaja hacia fuera, hacia la integracin de todo el sistema de cmputo. Diferentes tcnicas de prueba son apropiadas en diferentes momentos, la prueba la dirige el desarrollador del software y (en el caso de proyectos grandes) un grupo independiente de pruebas. La prueba y la depuracin son actividades diferentes, pero la segunda debe incluirse en la primera.

Aspectos estratgicos Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas. Establecer los objetivos de la prueba de manera explcita. Comprender que usuarios van a tener el software y desarrollar un perfil para cada categora de usuario. Desarrollar un plan de prueba que haga hincapi en la prueba de ciclo. Construir un software robusto diseado para probarse a s 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.

Estrategia de Prueba Para Arquitecturas Convencionales de Software El desarrollo de sw requiere recorrer la espiral hacia dentro, a lo largo de una lnea bien definida que disminuye el grao de abstraccin tras cada vuelta el sw se prueba recorre la espiral hacia fuera, por una lnea bien definida, de manera que en cada vuelta se ensancha el alcance de la prueba. Prueba de unidad Se concentra en el esfuerzo de verificacin de la unidad ms pequea del diseo del sw: el componente o mdulo de sw. La interfaz del mdulo se prueba para asegurar que la informacin fluya apropiadamente hacia dentro y hacia fuera de la unidad de programa sujeta a prueba. Se examinan las estructuras de datos locales para asegurar que los datos mantienen la integridad durante todos los pasos de la ejecucin, se recorren todos los caminos independientes en toda la estructura para asegurarse que todas las instrucciones de un mdulo se hayan ejecutado por lo menos una vez, por ltimo se prueban todos los caminos de manejo de errores, el nmero de casos de prueba se reduce y es ms fcil predecir y corregir los errores. Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del mdulo. Si los datos no entran correctamente, todas las dems pruebas no tienen sentido. Por eso se toma en cuenta si: 1. 2. 3. 4. Es igual el nmero de parmetros de entrada al nmero de argumentos? Coinciden los atributos de los parmetros y los argumentos? Coinciden los sistemas de unidades de los parmetros y de los argumentos? Es igual el nmero de argumentos transmitidos a los mdulos de llamada que el nmero de parmetros? 5. Son iguales los atributos de los argumentos transmitidos a los mdulos de llamada y los atributos de los parmetros? Son iguales los sistemas de unidades de los argumentos transmitidos a los mdulos de llamada y de los parmetros? Son correctos el nmero de los atributos y el orden de los argumentos de las funciones incorporadas?

5. 6. 7.

8.

Existen referencias a parmetros que no estn asociados con el punto de entrada actual? 9. Entran slo argumentos alterados? 10. Son consistentes las definiciones de variables globales entre los mdulos? 11. Se pasan las restricciones como argumentos?

Un buen diseo exige que las condiciones de error sean previas de antemano y que se dispongan unos caminos de manejo de errores que redirijan o terminen de una forma limpia el proceso cuando se d un error. Entre los errores potenciales que se deben comprobar cuando se evala la manipulacin de errores estn: Descripcin ininteligible del error. El error sealado no se corresponde con el error encontrado. La condicin de error hace que intervenga el sistema antes que el mecanismo de manejo de errores. El proceso de la condicin excepcional es incorrecto. La descripcin del error no proporciona suficiente informacin para ayudar en la localizacin de la causa del error.

El diseo de casos de prueba de unidad comienza una vez que se ha desarrollado, revisado y verificado el cdigo a nivel de fuente. Cada caso de prueba debe ir acompaado de un conjunto de resultados esperados. Prueba de integracin Es una tcnica sistemtica para construir la arquitectura del sw mientras, se aplican las pruebas para descubrir errores asociados con la interfaz. El objetivo es coger los mdulos probados en unidad y construir una estructura de programa que est de acuerdo con lo que dicta el diseo. El proceso de integracin se realiza en una serie de cinco pasos: 1. Se usa l modulo de control principal como controlador de la prueba, disponiendo de back ups para todos los mdulos directamente subordinados al modulo de control principal. 2. Dependiendo del enfoque de integracin elegido se van sustituyendo los back ups subordinados uno a uno por los mdulos reales. 3. Se llevan a cabo pruebas cada vez que se integra un nuevo modulo. 4. Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con l modulo real. 5. Se hace la prueba de regresin para asegurarse de que no se han introducido errores nuevos. Integracin ascendente La prueba de la integracin ascendente, como su nombre indica, empieza la construccin y la prueba con los mdulos atmicos (es decir, mdulos de los niveles ms bajos de la estructura del programa). Dado que los mdulos se integran de abajo hacia arriba, el proceso requerido de los mdulos subordinados a un nivel dado siempre estn disponibles y se elimina la necesidad de resguardos. La estrategia descendente parece relativamente fcil, pero, en la prctica, pueden surgir algunos problemas logsticos. El ms comn de estos problemas se da cuando se requiere un proceso de los niveles ms bajos de la jerarqua para poder probar adecuadamente los niveles superiores.

Integracin descendente La integracin descendente es un planteamiento incremental a la construccin de la estructura de programas. Se integran los mdulos movindose hacia abajo por la jerarqua de control, comenzando por el mdulo de control principal (programa principal). Los mdulos subordinados (de cualquier modo subordinados) al mdulo de control principal se van incorporando en la estructura, bien de forma primero-enprofundidad o bien de forma primero-en-anchura. Se puede implementar una estrategia de integracin ascendente mediante los siguientes pasos: 1. 2. 3. 4. 5. Se combinan los mdulos de bajo nivel en grupos que realicen una subfuncin especfica del software. Se escribe un controlador para coordinar la entrada y la salida de los casos de prueba. Se prueba el grupo. Se eliminan los controles y se combinan los grupos movindose hacia arriba por la estructura del programa. A medida que la integracin progresa hacia arriba, disminuye la necesidad de controladores de prueba diferentes.

Prueba de regresin Cada vez que se aade un nuevo mdulo como parte de una prueba de integracin, el software cambia. Estos cambios pueden causar problemas con funciones que antes trabajaban perfectamente. En el contexto de una estrategia de prueba de integracin, la prueba de regresin es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse que los cambios no han propagado efectos colaterales no deseados. Tras la culminacin de la prueba de integracin, el software est completamente ensamblado como un paquete; se han encontrado y corregido los errores de interfaz y puede comenzar una serie final de pruebas del software: la prueba de validacin. La validacin puede definirse de muchas formas, pero una simple (aunque vulgar) definicin es que la validacin se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente. En este punto, un desarrollador de software estricto podra protestar: Qu o quin es el rbitro de las expectativas razonables?. La prueba del sw es un elemento de un tema ms amplio que suele denominarse verificacin y validacin. La prueba del software es un elemento de un tema ms amplio que, a menudo, se le conoce como verificacin y validacin (V&V). La verificacin se refiere al conjunto de actividades que aseguran que el software implementa correctamente una funcin especfica. La validacin se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente. Bohem lo define de otra forma: Verificacin: Es el conjunto de actividades que aseguran que el sw implemente correctamente una funcin especfica Estamos construyendo el producto correctamente?

Validacin: Es un conjunto diferente de actividades que aseguran que el sw construido corresponde a los requisitos del cliente Estamos construyendo el producto correcto? El desarrollador del sw siempre ser el responsable de probar las unidades individuales (componentes) del programa y asegurar que cada una realice la funcin o muestre el comportamiento para el que se dise en muchos casos, el desarrollador tambin aplica la prueba de integracin slo despus de que la arquitectura del sw est completa participar un grupo independiente de prueba. El papel de un grupo independiente de prueba consiste en eliminar los problemas propios de dejar que el constructor pruebe lo que l mismo ha construido la prueba independiente elimina el conflicto de intereses que, de otra manera, estara presente se les paga para que encuentren errores el desarrollador y el GIP deben trabajar unidos en todo el proyecto de sw para asegurar la realizacin de pruebas exhaustivas el desarrollador debe estar disponible para corregir los errores que se descubran. La prueba constituye el ltimo bastn desde el que se puede evaluar la calidad y de forma ms pragmtica, descubrir los errores.

PRUEBA DEL SISTEMA Finalmente, el software es incorporado a otros elementos del sistema (nuevo hardware) y realizan una serie de pruebas de integracin del sistema y de validacin. Estas pruebas caen fuera del mbito del proceso de ingeniera del software y no las realiza nicamente el desarrollador del software. Prueba de recuperacin Muchos sistemas basados en computadora deben recuperarse de los fallos y continuar el proceso en un tiempo previamente especificado. En algunos casos, un sistema debe ser tolerante con los fallos; es decir, los fallos del proceso no deben hacer que cese el funcionamiento de todo el sistema. En otros casos, se debe corregir un fallo del sistema en un determinado periodo de tiempo para que no se produzca un serio dao econmico. 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. Cualquier sistema basado en computadora que maneje informacin sensible o lleve a cabo acciones que puedan perjudicar (o beneficiar) impropiamente a las personas es un posible objetivo para entradas al sistema impropias o ilegales. Este acceso al sistema incluye un amplio rango de actividades: piratas informticos que intentan entrar en los sistemas por deporte, empleados disgustados que intentan penetrar por venganza e individuos deshonestos que intentan penetrar para obtener ganancias personales ilcitas.

Prueba de resistencia En esencia, el sujeto que realiza la prueba de resistencia se pregunta: A qu potencia puedo ponerlo a funcionar antes de que falle?

Las pruebas de resistencia estn diseadas para enfrentar a los programas con situaciones anormales.

En general, el mejor compromiso puede ser un enfoque combinado que use la descendencia para los niveles superiores de la estructura del programa, junto con la ascendente para los niveles subordinados. Un modulo crtico es aquel que tiene una o ms de las siguientes caractersticas: Esta dirigido a varios requisitos del software; Tiene un mayor nivel de control Es complejo o propenso a errores Se tiene unos requisitos de rendimiento muy definidos.

Un plan global para la integracin del software y una descripcin de las pruebas especficas deben quedar documentados en una especificacin de prueba. Esquema de una especificacin de prueba que puede usarse como marco de trabajo para este documento es: mbito de la prueba Plan de prueba. Procedimiento de prueba Resultados reales de la prueba.

Você também pode gostar