Estrategia de prueba del software. Visión general.
Una estrategia para probar software puede verse como una espiral. La prueba de unidad comienza en el vértice de la espiral y se concentra en cada unidad del software como se implementó en el código fuente. La prueba avanza al moverse hacia afuera a lo largo de la espiral, hacia la prueba de integración, donde el enfoque se centra en el diseño y la construcción de la arquitectura del software. Al dar otra vuelta hacia afuera de la espiral, se encuentra la prueba de validación, donde los requerimientos establecidos como parte de su modelado se validan confrontándose con el software que se construyó. Finalmente, se llega a la prueba del sistema, donde el software y otros elementos del sistema se prueban como un todo. Para probar el software de cómputo, se avanza en espiral hacia afuera en dirección de las manecillas del reloj a lo largo de líneas que ensanchan el alcance de las pruebas con cada vuelta. Mientras que para el para desarrollar software de computadoras, se avanza en espiral hacia adentro (contra las manecillas del reloj) a lo largo de una línea que reduce el nivel de abstracción en cada vuelta.
Con la técnica de considerar el proceso desde un punto de vista procedural, las pruebas dentro del contexto de la ingeniería del software en realidad son una serie de cuatro pasos que se implementan de
manera secuencial.
Inicialmente, las pruebas se enfocan en cada componente de manera individual, lo que garantiza que funcionan adecuadamente como unidad. De ahí el nombre de prueba de unidad. Esta prueba utiliza mucho de las técnicas de prueba que ejercitan rutas específicas en una estructura de control de componentes para asegurar una cobertura completa y la máxima detección de errores. A continuación, los componentes deben ensamblarse o integrarse para formar el paquete de software completo. La prueba de integración aborda los conflictos asociados con los problemas duales de verificación y construcción de programas.
Durante la integración, se usan más las técnicas de diseño de casos de prueba que se enfocan en entradas y salidas, aunque también pueden usarse técnicas que ejercitan rutas de programa específicas para asegurar la cobertura de las principales rutas de control. Después de integrar (construir) el software, se realiza una serie de pruebas de orden superior. Deben evaluarse criterios de validación (establecidos durante el análisis de requerimientos). La prueba de validación proporciona la garantía final de que el software cumple con todos los requerimientos informativos, funcionales, de comportamiento y de rendimiento.
Criterios para completar las pruebas
Cada vez que se analiza la prueba del software, surge una pregunta clásica: “¿cuándo terminan
las pruebas?, ¿cómo se sabe que se ha probado lo suficiente?”.Una respuesta a la pregunta es: “nunca se termina de probar; la carga simplemente pasa de usted (el ingeniero de software) al usuario final”. Cada vez que el usuario ejecuta un programa de cómputo, el programa se pone a prueba. Este instructivo hecho subraya la importancia de otras actividades a fin de garantizar la calidad del software. Otra respuesta (un tanto cínica, mas no obstante precisa) es: “las pruebas terminan cuando se agota el tiempo o el dinero”.
Otro enfoque sugiere la utilización de un método que sea mas confiable que la simple intuición, entonces se han realizado propuestas como:
- El uso de técnicas estadísticas que ejecutan una serie de pruebas derivadas de una muestra estadística de todas las posibles ejecuciones de programa por parte de todos los usuarios de una población objetivo.
- El uso del modelado estadístico y la teoría de confiabilidad del software para predecir cuándo están completas las pruebas.
ASPECTOS ESTRATÉGICOS
Una estrategia de software triunfará cuando quienes prueban el software:
- Especifican los requerimientos del producto en forma cuantificable mucho antes de comenzar con las pruebas.
- Establecen de manera explícita los objetivos de las pruebas.
- Entienden a los usuarios del software y desarrollan un perfil para cada categoría de usuario.
- Desarrollan un plan de prueba que enfatice “pruebas de ciclo rápido”.
- Construyen software “robusto” que esté diseñado para probarse a sí mismo.
- Usan revisiones técnicas efectivas como filtro previo a las pruebas.
- Realizan revisiones técnicas para valorar la estrategia de prueba y los casos de prueba.
- Desarrollan un enfoque de mejora continuo para el proceso de prueba.
ESTRATEGIAS DE PRUEBA PARA SOFTWARE CONVENCIONAL
Una estrategia de prueba que eligen la mayoría de los equipos de software se coloca entre los dos extremos. Toma una visión incremental de las pruebas, comenzando con la de unidades de programa individuales, avanza hacia pruebas diseñadas para facilitar la integración de las unidades y culmina con pruebas que ejercitan el sistema construido.
Prueba de unidad
La prueba de unidad enfoca los esfuerzos de verificación en la unidad más pequeña del diseño de software: el componente o módulo de software. Al usar la descripción del diseño de componente como guía, las rutas de control importantes se prueban para descubrir errores dentro de la frontera del módulo. La relativa complejidad de las pruebas y los errores que descubren están limitados por el ámbito restringido que se establece para la prueba de unidad. Las pruebas de unidad se enfocan en la lógica de procesamiento interno y de las estructuras de datos dentro de las fronteras de un componente.
Consideraciones de las pruebas de unidad.
La interfaz del módulo se prueba para garantizar que la información fluya de manera adecuada hacia y desde la unidad de software que se está probando. Las estructuras de datos locales se examinan para asegurar que los datos almacenados temporalmente mantienen su integridad durante todos los pasos en la ejecución de un algoritmo. Todas las rutas independientes a través de la estructura de control se ejercitan para asegurar que todos los estatutos en un módulo se ejecuten al menos una vez. Las condiciones de frontera se prueban para asegurar que el módulo opera adecuadamente en las fronteras establecidas para limitar o restringir el procesamiento. Y, finalmente, se ponen a prueba todas las rutas para el manejo de errores.
Procedimientos de prueba de unidad.
Las pruebas de unidad por lo general se consideran como adjuntas al paso de codificación. El diseño de las pruebas de unidad puede ocurrir antes de comenzar la codificación o después de generar el código fuente. La revisión de la información del diseño proporciona una guía para establecer casos de prueba que es probable que descubran errores en cada una de las categorías analizadas anteriormente. Cada caso de prueba debe acoplarse con un conjunto de resultados esperados.
Puesto que un componente no es un programa independiente, con frecuencia debe desarrollarse software controlador y/o de resguardo para cada prueba de unidad.
Las pruebas de unidad se simplifican cuando se diseña un componente con alta cohesión. Cuando un componente aborda una sola función, el número de casos de prueba se reduce y los errores pueden predecirse y descubrirse con mayor facilidad.
Pruebas de integración
Las pruebas de integración son una técnica sistemática para construir la arquitectura del software mientras se llevan a cabo pruebas para descubrir errores asociados con la interfaz. El objetivo es tomar los componentes probados de manera individual y construir una estructura de programa que se haya dictado por diseño.
Con frecuencia existe una tendencia a intentar la integración no incremental, es decir, a construir el programa usando un enfoque de big bang, lo cual ante la aparición de errores y debido a la extensión del desarrollo termina en un caos y un bucle de revisiones. La integración incremental es la antítesis del enfoque big bang. El programa se construye y prueba en pequeños incrementos, donde los errores son más fáciles de aislar y corregir; las interfaces tienen más posibilidades de probarse por completo; y puede aplicarse un enfoque de prueba sistemático.
Integración descendente.
La prueba de integración descendente es un enfoque incremental a la construcción de la arquitectura de software. Los módulos se integran al moverse hacia abajo a través de la jerarquía de control, comenzando con el módulo de control principal programa principal). Los módulos subordinados al módulo de control principal se incorporan en la estructura en una forma de primero en profundidad o primero en anchura.
la integración primero en profundidad integra todos los componentes sobre una ruta de control mayor de la estructura del programa. La integración primero en anchura incorpora todos los componentes directamente subordinados en cada nivel, y se mueve horizontalmente a través de la estructura.
El proceso de integración se realiza en una serie de cinco pasos:
- El módulo de control principal se usa como un controlador de prueba y los representantes (stubs) se sustituyen con todos los componentes directamente subordinados al módulo de control principal.
- Dependiendo del enfoque de integración seleccionado (es decir, primero en profundidad o anchura), los representantes subordinados se sustituyen uno a la vez con componentes reales.
- Las pruebas se llevan a cabo conforme se integra cada componente.
- Al completar cada conjunto de pruebas, otro representante se sustituye con el componente real.
- Las pruebas de regresión (que se analizan más adelante en esta sección) pueden realizarse para asegurar que no se introdujeron nuevos errores.
Integración ascendente.
La prueba de integración ascendente, como su nombre implica, comienza la construcción y la prueba con módulos atómicos (es decir, componentes en los niveles inferiores dentro de la estructura del programa). Puesto que los componentes se integran de abajo hacia arriba, la funcionalidad que proporcionan los componentes subordinados en determinado nivel siempre está disponible y se elimina la necesidad de representantes (stubs).
Una estrategia de integración ascendente puede implementarse con los siguientes pasos:
- Los componentes en el nivel inferior se combinan en grupos (en ocasiones llamados construcciones o builds) que realizan una subfunción de software específica.
- Se escribe un controlador (un programa de control para pruebas) a fin de coordinar la entrada y salida de casos de prueba.
- Se prueba el grupo.
- Los controladores se remueven y los grupos se combinan moviéndolos hacia arriba en la estructura del programa.
Conforme la integración avanza hacia arriba, se reduce la necesidad de controladores de prueba separados. De hecho, si los dos niveles superiores del programa se integran de manera descendente, el número de controladores puede reducirse de manera sustancial y la integración de grupos se simplifica enormemente.
Prueba de regresión.
Cada vez que se agrega un nuevo módulo como parte de las pruebas de integración, el software cambia. Se establecen nuevas rutas de flujo de datos, ocurren nuevas operaciones de entrada/salida y se invoca nueva lógica de control. Dichos cambios pueden causar problemas con las funciones que anteriormente trabajaban sin fallas. En el contexto de una estrategia de prueba de integración, la prueba de regresión es la nueva ejecución de algún subconjunto de pruebas que ya se realizaron a fin de asegurar que los cambios no propagaron efectos colaterales no deseados.
Las pruebas de regresión ayudan a garantizar que los cambios (debidos a pruebas o por otras razones) no introducen comportamiento no planeado o errores adicionales.
Las pruebas de regresión se pueden realizar manualmente, al volver a ejecutar un subconjunto de todos los casos de prueba o usando herramientas de captura/reproducción automatizadas. Las herramientas de captura/reproducción permiten al ingeniero de software capturar casos de prueba y resultados para una posterior reproducción y comparación. La suite de prueba de regresión (el subconjunto de pruebas que se va a ejecutar) contiene tres clases diferentes de casos de prueba:
- Una muestra representativa de pruebas que ejercitará todas las funciones de software.
- Pruebas adicionales que se enfocan en las funciones del software que probablemente resulten afectadas por el cambio.
- Pruebas que se enfocan en los componentes del software que cambiaron.
Prueba de humo.
La prueba de humo es un enfoque de prueba de integración que se usa cuando se desarrolla software de producto. Se diseña como un mecanismo de ritmo para proyectos críticos en el tiempo, lo que permite al equipo del software valorar el proyecto de manera frecuente.
En esencia, el enfoque de prueba de humo abarca las siguientes actividades:
- Los componentes de software traducidos en código se integran en una construcción.
- Se diseña una serie de pruebas para exponer los errores que evitarán a la construcción realizar adecuadamente su función.
- La construcción se integra con otras construcciones, y todo el producto (en su forma actual) se somete a prueba de humo diariamente.
La prueba de humo proporciona algunos beneficios cuando se aplica sobre proyectos de
software complejos y cruciales en el tiempo:
- Se minimiza el riesgo de integración.
- La calidad del producto final mejora.
- El diagnóstico y la corrección de errores se simplifican.
- El progreso es más fácil de valorar.
Opciones estratégicas.
La selección de una estrategia de integración depende de las características del software y, en ocasiones, del calendario del proyecto. En general, un enfoque combinado (a veces llamado prueba sándwich), que usa pruebas descendentes para niveles superiores de la estructura del programa acopladas con pruebas ascendentes para niveles subordinados, puede ser el mejor arreglo.
Conforme se realiza la integración, quien efectúa la prueba debe identificar los módulos críticos. Un módulo crítico tiene una o más de las siguientes características: 1) aborda muchos requerimientos de software, 2) tiene un alto nivel de control (reside relativamente alto en la estructura del programa), 3) es complejo o proclive al error o 4) tiene requerimientos de rendimiento definidos. Los módulos críticos deben probarse tan pronto como sea posible. Además, las pruebas de regresión deben enfocarse en la función del módulo crítico.
Productos de trabajo de las pruebas de integración.
Un plan global para integración del software y una descripción de las pruebas específicas se documentan en una Especificación de pruebas. Este producto de trabajo incorpora un plan de prueba y un procedimiento de prueba, y se vuelve parte de la configuración del software. La prueba se divide en fases y construcciones que abordan características del software funcionales y de comportamiento específicas.
.Los siguientes criterios y pruebas correspondientes se aplican a todas las fases de prueba:
- Integridad de interfaz. Las interfaces internas y externas se prueban conforme cada módulo (o grupo) se incorpora en la estructura.
- Validez funcional. Se realizan pruebas diseñadas para descubrir errores funcionales ocultos.
- Contenido de la información. Se realizan pruebas diseñadas para descubrir errores ocultos asociados con las estructuras de datos locales o globales.
- Rendimiento. Se realizan pruebas diseñadas para verificar los límites del rendimiento establecidos durante el diseño del software.
A continuación se describe el procedimiento de prueba detallado que se requiere para lograr el plan de prueba. Se señala el orden de la integración y las pruebas correspondientes en cada paso de ésta. También se incluye una lista de todos los casos de prueba (anotados para referencia posterior) y los resultados esperados.
En un Reporte de prueba, que puede anexarse a la Especificación pruebas si se desea, se registra una historia de resultados, problemas o peculiaridades de prueba reales. La información contenida en esta sección puede ser vital durante el mantenimiento del software. También se presentan las referencias y apéndices apropiados.
Referencia:
Pressman, Roger, S. (2010). Ingeniería de software. McGRAW-HILL.
No hay comentarios.:
Publicar un comentario