Flujo de pruebas de un software

Flujo de pruebas de un software Flujo de pruebas de un software

Flujo de pruebas de un software El software es refinado a través de iteraciones en el ciclo de vida. El ciclo de vida de prueba se beneficia siguiendo un proceso iterativo equivalente. En cadaiteración el equipo de desarrollo produce uno o más builds, cada builds es un candidato potencial para probar. Los objetivos del equipo de desarrollo difieren de una iteración a otra. El equipo de prueba estructura su prueba de acuerdo a los objetivos de la iteración.

Niveles de Prueba

La Prueba es aplicada para diferentes tipos de objetivos, en diferentes escenarios o niveles de trabajo.

Se distinguen los siguientes niveles de pruebas

•Prueba de desarrollador •Prueba de Unidad •Prueba de Integración •Prueba de sistema •Prueba de aceptación

Prueba de Desarrollador

Es la prueba diseñada e implementada por el equipo de desarrollo. Tradicionalmente estas pruebas han sido consideradas solo para la prueba de unidad, aunque en la actualidad en algunos casos pueden ejecutar pruebas de integración. Se recomienda que estas pruebas cubran más que las pruebas de unidad.

Prueba independiente

Es la prueba que es diseñada e implementada por alguien independiente del grupo de desarrolladores. El objetivo de estas pruebas es proporcionar una perspectiva deferente y en un ambiente más rico que los desarrolladores. Una vista de la prueba independiente es la prueba independiente de los stakeholder, que son pruebas basadas en las necesidades y preocupaciones de los stakeholders.

Prueba de unidad

Es la prueba enfocada a los elementos testeables más pequeño del software. Es aplicable a componentes representados en el modelo de implementación para verificar que los flujos de control y de datos están cubiertos, y que ellos funcionen como se espera. La prueba de unidad siempre está orientada a caja blanca.

Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del componente.

Si los datos no entran correctamente, todas las demás pruebas no tienen sentido. El diseño de casos de prueba de una unidad comienza una vez que se ha desarrollado, revisado y verificado en su sintaxis el código a nivel fuente.

Prueba de unidad en el contexto OO. En lugar de módulos individuales, una menor unidad a probar es la clase u objeto encapsulado. Una clase puede contener un cierto número de operaciones, y una operación particular puede existir como parte de un número de clases diferentes. Esta prueba de clases para el software OO es equivalente a la prueba de unidad para el software convencional.

La prueba de clases para software OO está dirigida por las operaciones encapsuladas por la clase y el estado del comportamiento de la clase. No se puede probar una operación aisladamente sino como parte de una clase.

Prueba de integración

Es ejecutada para asegurar que los componentes en el modelo de implementación operen correctamente cuando son combinados para ejecutar un caso de uso. Se prueba un paquete o un conjunto de paquetes del modelo de implementación. Estas pruebas descubren errores o incompletitud en las especificaciones de las interfaces de los paquetes. Esta prueba debe ser responsabilidad de desarrolladores y de independientes, sin solaparse las pruebas.

Es el proceso de combinar y probar múltiples componentes juntos. El objetivo es tomar los componentes probados en unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño.

Se llama integración incremental cuando el programa se construye y se prueba en pequeños segmentos en los que los errores son más fáciles de aislar y corregir, es más probable que se pueda probar completamente las interfaces y se puede aplicar un enfoque de prueba sistemática.

Hay dos estrategias de integración incremental:

Integración Descendente (Top-Down)

Se integran los módulos moviéndose hacia abajo por la jerarquía de control. Comenzando por el módulo principal, los módulos subordinados se van incorporando a la estructura bien, en forma primero en profundidad, que integra todos los módulos de un camino de control principal de la estructura, o primero en anchura, que incorpora todos los módulos directamente subordinados a cada nivel, moviéndose por la estructura de forma horizontal.

Este proceso se realiza en una serie de cinco pasos:

1. Se usa el módulo de control principal como controlador de la prueba, disponiendo de resguardos para todos los módulos directamente subordinados al módulo de control principal. 2.Dependiendo del enfoque de integración elegido se van sustituyendo los resguardos subordinados uno a unopor los módulos reales. 3. Se llevan a cabo pruebas cada vez que se integra un nuevo módulo. 4. Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el módulo real. 5. Se hace la prueba de regresión para asegurarse de que no se han introducido errores nuevos.

El programa continúa desde el paso 2 hasta que se haya construido la estructura del programa entero.

Al aplicar esta estrategia pueden surgir algunos problemas, el más común se da cuando se requiere un proceso de los niveles más bajos de la jerarquía para poder probar adecuadamente los niveles superiores. Al principio de la prueba descendente, los módulos de bajo nivel se reemplazan por resguardos; por tanto, no pueden fluir datos significativos hacia arriba por la estructura del programa.

Para solucionar esto se tienen tres opciones:

-Retrasar muchas de las pruebas hasta que los resguardos sean reemplazados por los módulos reales. -Desarrollar resguardos que realicen funciones limitadas que simulen los módulos reales. -Integrar el software desde el fondo de la jerarquía hacia arriba.

Integración Ascendente (Bottom-Up)

Empieza la construcción y la prueba con los módulos de los niveles más bajos de la estructura del programa. Dado que los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados a un nivel dado siempre están disponibles y se elimina la necesidad de resguardos.

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 subfunción específica del software. 2. Se escribe un controlador para coordinar la entrada y la salida de los casos de prueba. 3. Seprueba el grupo. 4. Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la estructura del programa.

A medidaque la integración progresa disminuye la necesidad de controladores de prueba diferentes. Laselección de una estrategia de integración depende de las características del software y de la planificación del proyecto.

Una buenaalternativa es usar una mezcla de las dos estrategias (Ascendente y Descendente) que use la descendente para los niveles superiores de la estructura, junto con la ascendente para los niveles subordinados.

A medidaque progresa la prueba de integración, se deben identificar los módulos críticos. Un módulo crítico es aquel que tiene las una o más de las siguientes características:

• Está dirigido avarios requisitos del software • Tiene un mayornivel de control • Es complejo opropenso a errores. • Tiene unosrequisitos de rendimiento muy definidos. • Los móduloscríticos deben probarse lo antes posible. En el caso de integrar varios módulos y se encuentra un error en el momento de integrarlos, se tiene que hacer una Prueba de Regresión.

Prueba de Regresión

Cada vez que se añade un nuevo módulo como parte de una prueba de integración, el software cambia.

Estos cambios pueden causar problemas con funciones que antes trabajaban perfectamente. La prueba de regresión es la actividad que ayuda a asegurar que los cambios no introducen un comportamiento no deseado o errores adicionales.

El conjunto de pruebas de regresión contiene tres clases diferentes de casos de prueba:

• Una muestra representativa de pruebas que ejercite todas las funciones del software. • Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el cambio. • Pruebas que se centran en los componentes del software que ha cambiado. No es práctico ni eficiente volver a ejecutar cada prueba de cada función del programa después de un cambio. Existen dos estrategias diferentes para pruebas de integración en sistemas OO [BIN94a]:

Prueba basada en hilos

Integra el conjunto de clases necesario para responder a una entrada o evento del sistema. Cada hilo se integra y prueba individualmente. Se aplica la prueba de regresión para asegurar que no ocurren efectos colaterales.

Prueba basada en uso

Comienza la construcción del sistema probando aquellas clases (llamadas independientes) que usan muy pocas de las clases servidor. Luego se comprueban la próxima capa de clases, llamadas clases dependientes, que usan las clases independientes. Esta secuencia de capas de clases dependientes continúahasta construir el sistema por completo.

Prueba de Sistema

Son las pruebas que se hacen cuando el software está funcionando como un todo.

Es la actividad de prueba dirigida a verificar el programa final, después que todos los componentes de software y hardware han sido integrados. En un ciclo iterativo estas pruebas ocurren más temprano, tan pronto como subconjuntos bien formados de comportamiento de caso de uso son implementados.

Tipo de Pruebas del Sistema

• Prueba de Recuperación: Es una prueba del sistema que fuerza el fallo del software de muchas

formas y verifica que la recuperación se lleva a cabo apropiadamente.

• Prueba de Seguridad:Intenta verificar que los mecanismosde protección incorporados en el sistema loprotegerán, de hecho, de acceso impropios.
• Prueba de Resistencia: Están diseñadas para enfrentar a los programas con situaciones anormales.
• Prueba de Rendimiento: Está diseñada para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado.

Prueba de aceptación

Prueba de aceptación del usuario es la prueba final antes del despliegue del sistema. Su objetivo es verificar que el software está listo y que puede ser usado por usuarios finales para ejecutar aquellas funciones y tareas para las cuales el software fue construido. Un comentario sobre la secuencia de los niveles de prueba.

Las pruebas de unidad son implementadas en la iteración más temprana como el primer nivel de prueba.

Pero en un proceso iterativo ejecutar todas las pruebas de unidad antes de pasar a niveles siguientes de prueba como regla es inapropiado. Una mejor estrategia es identificar las pruebas de unidad, integración y sistema que ofrecen mayor potencial para encontrar errores y entonces implementarlas y ejecutarlas.

Tipos de Prueba

Funcionalidad

Función:Pruebas fijando su atención en la validación de las funciones, métodos, servicios, caso de uso.

Seguridad: Asegurar que los datos o el sistema solamente es accedido por los actores deseados.

Volumen: Enfocada en verificando las habilidades de los programas para manejar grandes cantidades de datos, tanto como entrada, salida o residente en la BD.

Usabilidad

Usabilidad: Prueba enfocada a factores humanos, estéticos, consistencia en la interfaz de usuario, ayuda sensitiva al contexto y en línea, asistente documentación de usuarios y materiales de entrenamiento.

Fiabilidad

Integridad: Enfocada a la valoración de la robustez (resistencia a fallos).

Estructura: Enfocada a la valoración a la adherencia a su diseño y formación. Este tipo de prueba es hecho a alas aplicaciones Web asegurando que todos los enlaces están conectados, el contenido deseado es mostrado y no hay contenido huérfano. Stress: Enfocada a evaluar cómo el sistema responde bajo condiciones anormales. (extrema sobrecarga, insuficiente memoria, servicios y hardware no disponible, recursos compartidos no disponible )

Performance (Rendimiento)

Benchmark: es un tipo de prueba que compara el rendimiento de un elemento nuevo o desconocido a uno de carga de trabajo de referencia conocido.

Contención: Enfocada a la validación de las habilidades del elemento a probar para manejar aceptablemente la demanda de múltiples actores sobre un mismo recurso (registro de recursos, memoria, etc) Carga: Usada para validar y valorar la aceptabilidad de lo límites operacionales de un sistema bajo carga de trabajo variable, mientras el sistema bajo prueba permanece constante. La variación en carga es simular la carga de trabajo promedio y con picos que ocurre dentro de tolerancias operacionales normales.

Performance profile: Enfocadas a monitorear el tiempo en flujo de ejecución, acceso a datos, en llamada a funciones y sistema para identificar y direccional los cuellos de botellas y los procesos ineficientes.

Soportabilidad

Configuracion: Enfocada a asegurar que funciona en diferentes configuraciones de hardware y software.

Esta prueba es implementada también como prueba de rendimiento del sistema Instalacion: Enfocada a asegurar la instalación en diferentes configuraciones de hardware y software bajo diferentes condiciones (insuficiente espacio en disco, etc)

Estrategiade Prueba

La estrategia de prueba describe el enfoque y los objetivosgenerales de las actividades de prueba. Incluye los niveles de prueba (unidad, integración, etc) a ser diseccionados y el tipo de prueba a ser ejecutadas (funcional, stress, etc).

La estrategia define:

• Técnicas de pruebas (manual o automática) y herramientas a ser usadas. • Qué criterios de éxitos y culminación de la prueba serán usados. • Consideraciones especiales afectadas por requerimientos de recursos o que tengan implicaciones en la planificación.

Usted enfoca diferentes tipos de pruebas en dependencia del número de iteraciones, eltamaño de la iteración y el tipo de proyecto que se está probando.

En los programas Orientados a Objetos la estrategia y las tácticas de las pruebascambian. Para probar los sistemas OO adecuadamente, se deben hacer tres cosas:

1. Ladefinición de las pruebas debe ampliarse para incluir técnicas de detección de errores aplicados a los modelos de Análisis y diseño Orientado a Objetos. 2. La estrategia para las pruebas de unidad e integración deben cambiar significativamente. 3. El diseño de casos de prueba debe tener en cuenta las características propias del software orientado a objetos.

Métodos de Prueba

Son dos fundamentales: el método de la caja negra y de la caja blanca. La prueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. O sea, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto, así como que la integridad de la información externa se mantiene.

La prueba de la caja blanca del software se comprueba los caminos lógicos del software proponiendo casos de prueba que se ejerciten conjuntos específicos de condiciones y/o bucles. Se puede examinar el estado del programa en varios puntos para determinar si el estado real coinciden con el esperado o mencionado.

Referencias