You are on page 1of 4

Aspectos estratgicos para las pruebas de software 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 soft ware 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) Verificacin: se refiere al conjunto de actividades que aseguran que el software implementa correctamente una funcin especfica. Validacin: 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 gracin, donde el foco de atencin es el diseo y la construccin de la arquitectura del software. La prueba de validacin, 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. Se prueba la interfaz del mdulo 2. Se examinan las estructuras de datos locales 3. Se prueban las condiciones lmite 4. Se ejercitan todos los caminos independientes 5. 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 puede 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 lis ta 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 Implantacin (conversin)

Por lo general al hablar de modelos de desarrollo de software se considera cuatro grandes fases: Anlisis, diseo, codificacin y prueba. Sin embargo, desde un punto de vista sistmico, se debe considerar 2 fases adicionales: la implantacin (conversin) y la produccin y mantenimiento, como se ve en la figura 4.1 Figura 4.1: Proceso de desarrollo de sistemas

P r o d u c c i n Y M a n te n im ie n to

A N A L IS IS

D IS E O C O N V E R S IO N

PRUEBA

P R O G R A M A C IO N

O R G A N IZ A C IO N

FUENTE: Management Information Systems: New Approaches to Organization & Technology, Kenneth C. Laudon, Jane P. Laudon, Captulo 11, Pgina 401, grfico 11.5, 5ta. Edicin en ingles. La implantacin (conversin) es el proceso de cambiar desde un sistema antiguo hacia un nuevo sistema 1, que no es otra cosa que alimentar de datos al nuevo sistema, tomando en cuenta que hablar de un sistema antiguo incluye sistemas de carcter manual. Existen bsicamente cuatro estrategias que permiten que este proceso se realice de forma eficiente y son: En paralelo: Cuando se utiliza ambos sistemas al mismo tiempo hasta que el nuevo sistema se muestre estable. Este esquema es ms seguro y permite realizar comparaciones de resultados, pero se debe considerar que el nuevo sistema tal vez contempla procesos que el anterior no tena y que se requiere el doble de tiempo. Cambio directo: Cuando se determina que el nuevo sistema debe reemplazar por completo al anterior y se usa el mismo en vez del otro para el desarrollo de actividades diarias. Esta estrategia es la ms riesgosa pero obliga a que la organizacin acepte el cambio. Estudio piloto: Cuando se introduce el nuevo sistema en un rea limitada de la organizacin hasta probar la funcionalidad del mismo, luego de lo cual se propaga el sistema al resto de la organizacin. Este tipo de estrategia presente un nivel de riesgo intermedio, pero su eficiencia depende de la correcta seleccin del rea de prueba. Por fases: Cuando el sistema es introducido en la organizacin en etapas basadas en las funciones del mismo o las reas de la organizacin. A ms de determinar una estrategia de conversin, es importante contar con: Plan de conversin: Que determine el calendario de actividades que se requieren para instalar el nuevo sistema; Documentacin: Tcnica y de usuario que determine de forma clara y precisa el funcionamiento y uso del sistema; y, Esquema de capacitacin: Que determine los mecanismos de capacitacin de uso del sistema, en funcin de los niveles de uso y acceso, nmero de participantes, nmero de instructores y materiales necesarios. BIBLIOGRAFA: Roger S. Pressman, (2005). Ingeniera del Software: Un Enfoque Prctico (6taed.), Mxico, McGraw-Hill

Kenneth C. Laudon, Jane P. Laudon, Management Information Systems, New Approaches to Organization and Technology, Captulo 11, Pgina 406, 5ta. Edicin. Traduccin literal del texto en ingls.

You might also like