Una estrategia de prueba del software integra los métodos de diseño de casos de pruebas del sw en una serie bien planeada de pasos que desembocará en la eficaz construcción del sw.
La estrategia proporciona un mapa que describe los pasos que se darán como parte de la prueba indica cuándo se planean y cuándo se dan estos pasos, cuánto esfuerzo, tiempo y recursos consumirán un enfoque estratégico para la prueba del software.
Una planilla para la prueba del software: Es un conjunto de pasos en los que podemos situar los métodos de diseño de casos de prueba.
Planilla, características generales:
La prueba comienza en el nivel de modulo y trabaja hacia fuera, hacia la integración de todo el sistema basado en computadora.
Según el momento son apropiadas diferentes técnicas de prueba. La prueba la lleva a cabo el responsable del desarrollo del software y para grandes proyectos un grupo independiente de pruebas. La prueba y la depuración son actividades diferentes, pero en la depuración se debe incluir estrategia de prueba. Una estrategia debe proporcionar una guía al profesional a parte de un conjunto de hitos1 para el jefe de proyecto.
1. indica una dirección en los caminos o señala los límites de un territorio:
el hito indicaba el término de la comarca.
La verificación se refiere al conjunto de actividades que aseguran que el software implementa correctamente una función específica. La validación se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos.
La prueba constituye el último bastón desde el que se puede evaluar la calidad y de forma más pragmática, descubrir los errores.
Es importante darse cuenta de que la verificación y la validación comprenden un amplio rango de actividades de SQA.
Organización para la prueba del software
El responsable del desarrollo no debería entrar en el proceso de prueba el software debe ser puesto a salvo de extraños que puedan probarlo de forma despiadada, los encargados de la prueba solo aparecen en el proyecto cuando comienzan las etapas de prueba.
El papel del grupo independiente de prueba (GIP) es eliminar los inherentes problemas asociados con el hecho de permitir al constructor que pruebe la que ha construido. El responsable del desarrollo y el GIP trabajan estrechamente a lo largo del proyecto de software para asegurar que se realizan pruebas exhaustivas.
El proceso de ingeniería del software se puede ver como una espiral, como inicialmente, la ingeniería del sistema define el papel del software y conduce al análisis de los requisitos del software, donde se establece el dominio de información, la función, el comportamiento, el rendimiento, las restricciones y los criterios de validación del software.
Si consideramos el proceso desde el punto de vista procedimental, la prueba, en el contexto de la ingeniería del software, realmente es una serie de cuatro pasos que se llevan a cabo secuencialmente:
· prueba de unidad
· la prueba de integración
· prueba de alto nivel
· la prueba de validación
La prueba nunca termina, ya que el responsable del desarrollo del software carga o pasa el problema al cliente.
Otra respuesta: terminada la prueba cuando se agota el tiempo o el dinero disponible para tal efecto.
Mediante la agrupación de métricas durante la prueba del software y haciendo uso de los modelos de fiabilidad del software existentes, es posible desarrollar directrices importantes para responder a la pregunta; ¿Cuándo terminamos la prueba?
Se han propuesto varias estrategias de prueba del sw en distintos libros todas proporcionan al desarrollador del sw una plantilla para pruebas un conjunto de pasos en que puedan incluir técnicas y métodos específicos del diseño de casos de prueban todas las estrategias de prueba tienen las siguientes características:
Para realizar pruebas efectivas un equipo de sw debe efectuar revisiones técnicas formales y efectivas, la prueba comienza al nivel de componentes y trabaja “hacia fuera”, hacia la integración de todo el sistema de cómputo. Diferentes técnicas 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 depuración son actividades diferentes, pero la segunda debe incluirse en la primera.
Aspectos estratégicos
· Si se desea implementar con éxito una estrategia de prueba del software. Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas.
· Establecer los objetivos de la prueba de manera explícita.
· Comprender que usuarios va a tener el software y desarrollar un perfil para cada categoría de usuario.
· Desarrollar un plan de prueba que haga hincapié en la prueba de ciclo.
· Construir un software robusto diseñado para probarse a sí mismo.
· Usar revisiones técnicas formales efectivas como filtro antes de la prueba.
· Llevar a cabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba.
· Desarrollar un enfoque de mejora continua al proceso de prueba. Debería medirse la estrategia de prueba.
La prueba del sw es un elemento de un tema más amplio que suele denominarse verificación y validación.
Verificación: Es el conjunto de actividades que aseguran que el sw implemente correctamente una función específica ¿Estamos construyendo el producto correctamente?
Validación: 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 función o muestre el comportamiento para el que se diseñó en muchos casos, el desarrollador también aplica la prueba de integración sólo después 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, estaría 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 realización de pruebas exhaustivas el desarrollador debe estar disponible para corregir los errores que se descubran.
Estrategia de Prueba Para Arquitecturas Convencionales de Software
El desarrollo de sw requiere recorrer la espiral hacia dentro, a lo largo de una línea bien definida que disminuye el grao de abstracción tras cada vuelta el sw se prueba recorre la espiral hacia fuera, por una línea bien definida, de manera que en cada vuelta se ensancha el alcance de la prueba.
Prueba de unidad
Se concentra en el esfuerzo de verificación de la unidad más pequeña del diseño del sw: el componente o módulo de sw.
La interfaz del módulo se prueba para asegurar que la información fluye 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 temporales mantienen la integridad durante todos los pasos de la ejecución de un algoritmo, se recorren todos los caminos independientes en toda la estructura para asegurar que todas las instrucciones de un módulo se hayan ejecutado por lo menos una vez por último, se prueban todos los caminos de manejo de errores la prueba de unidad se simplifica cuando se diseña un componente con una cohesión elevada cuando sólo se atiende una función de un componente, el número de casos de prueba se reduce y es más fácil predecir y corregir los errores.
La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software: él módulo. La prueban las condiciones límite para asegurar que él módulo funciona correctamente en los límites establecidos. Se ejercitan todos los caminos independientes, caminos básicos de la estructura de control con el fin de asegurar que todas las sentencias del modulo se ejercitan por lo menos una vez. Y, finalmente, se prueban todos los caminos de manejo de errores.
Durante la prueba de unidad, la comprobación selectiva de los caminos de ejecución es una tarea esencial. Se deben diseñar casos de prueba para detectar errores debidos a cálculos incorrectos, comparaciones incorrectas o flujos de control inapropiados.
Un buen diseño 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 evalúa la manipulación de errores están:
· Descripción ininteligible del error.
· El error señalado no se corresponde con el error encontrado.
· La condición de error hace que intervenga el sistema antes que el mecanismo de manejo de errores.
· El proceso de la condición excepcional es incorrecto.
· La descripción del error no proporciona suficiente información para ayudar en la localización de la causa del error.
El diseño de casos de prueba de unidad comienza una vez que se ha desarrollado, revisado y verificado en su sintaxis el código a nivel de fuente. Un repaso de la información del diseño proporciona directrices para el establecimiento de los casos de prueba que más probablemente descubrirán errores de las categorías previamente mencionadas. Cada caso de prueba debe ir acompañado de un conjunto de resultados esperados.
Prueba de integración
Es una técnica sistemática para construir la arquitectura del sw mientras, al mismo tiempo, se aplican las pruebas para descubrir errores asociados con la interfaz.
En una interfaz es posible perder datos, un módulo podría tener un efecto adverso e inadvertido sobre otro, la combinación de sub-funciones tal vez no produzca la función principal deseada.
La prueba de integración también sistemática para construir la estructura del programa mientras que, al mismo tiempo, se llevan, a cabo pruebas para detectar errores asociados con la interacción. El objetivo es coger los módulos probados en unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño. Integración no incremental; big bang normalmente se llega al caos. La integración incremental es la antítesis del enfoque del big bang.
La integración descendente en un planteamiento incremental a la construcción de la estructura de programas. Se integran los módulos moviéndose hacia abajo por la jerarquía de control. Comenzando por él modulo de control principal los módulos subordinados. Al módulo de control principal se van incorporando en la estructura, bien de forma primero en profundidad, o bien de forma primero en anchura.
El proceso de integración se realiza en una serie de cinco pasos:
1. Se usa él modulo de control principal como controlador de la prueba, disponiendo de resguardos para todos los módulos directamente subordinados al modulo de control principal.
2. Dependiendo del enfoque de integración elegido se van sustituyendo los resguardos subordinados uno a uno por los módulos 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 regresión para asegurarse de que no se han introducido errores nuevos.
La estrategia descendente parece relativamente fácil, pero, en la práctica, pueden surgir algunos problemas logísticos. El más común de estos problemas se da cuando se requiere un proceso de los niveles más bajos de la jerarquía para poder probar adecuadamente los niveles superiores.
La prueba de la integración ascendente, como su nombre indica, empieza la construcción y la prueba con los módulos atómicos.
Se puede implementar una estrategia de integración ascendente mediante los siguientes pasos:
1. Se combinan los módulos de bajo nivel en grupos que realicen una sub-función específica 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 controles y se combinan los grupos moviéndose hacia arriba por la estructura del programa.
5. A medida que la integración progresa hacia arriba, disminuye la necesidad de controladores de prueba diferentes.
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 crítico es aquel que tiene una o más de las siguientes características:
· 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 integración del software y una descripción de las pruebas específicas deben quedar documentados en una especificación de prueba. Esquema de una especificación 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.
