CAPITULO 17: “ESTRATEGIAS DE PRUEBA DE SOFTWARE”

CAPITULO 17: “ESTRATEGIAS DE PRUEBA DE SOFTWARE”

Un enfoque estratégico para la prueba de software
La prueba es un conjunto de actividades que pueden planearse por adelantado y realizarse de manera sistemática. Un conjunto de pasos que incluyen métodos de prueba y técnicas de diseño de casos de prueba específicos.

Verificación y Validación

Verificación: Conjunto de tareas que garantizan que el SW implementa correctamente una función específica.

Validación: Conjunto diferente de tareas que aseguran que el sw que se construye sigue los requerimientos del cliente.

Las pruebas representan el ultimo bastión desde donde puede valorarse la calidad y descubrir errores.

Organización de las pruebas del Software

Cuando la arquitectura de sw está completa, se involucra un grupo de prueba independiente (GPI).

El papel de un grupo de prueba independiente (GPI) es remover las pruebas inherentes que están asociados con dejar al constructor probar lo que construyó.

Las pruebas independientes remueven el conflicto de intereses que de otro modo puede estar presente. Se les paga por encontrar errores.

Estrategia de prueba del software. Vision general

Inicialmente la ingeniería de sistemas define el papel del software y conduce al análisis de los requerimientos del mismo. Al avanzar, se llega al diseño y finalmente a la codificación.

La estrategia para probar el sw se puede ver en contexto de una espiral: la prueba de unidad, comienza en el vértice de la espiral y se concentra en cada unidad del sw, como se implemento en el código fuente. La prueba avanza y se mueve hacia afuera a lo largo de la espiral hacia la Prueba de integración, donde el enfoque 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.

Aspectos estratégicos

• Especifican los requerimientos del producto en forma cuantificable mucho antes de comenzar con las pruebas. Esto debe especificarse en una forma medible, de modo que los resultados de las pruebas no sean ambiguos.
• Establecen de manera explícita los objetivos de las pruebas. Los objetivos específicos de las pruebas deben enunciarse en términos medibles
• Entienden a los usuarios del software y desarrollan un perfil para cada categoría de usuario. Los casos de uso que describen el escenario de interacción para cada clase de usuario pueden reducir el esfuerzo de prueba global al enfocar las pruebas en el uso real del producto.
• Desarrollan un plan de prueba que enfatice “pruebas de ciclo rápido”. La retroalimentación generada a partir de estas pruebas de ciclo rápido puede usarse para controlar niveles de calidad y las correspondientes estrategias de prueba.
• Construyen software “robusto” que esté diseñado para probarse a sí mismo. El software debe diseñarse en forma que use técnicas antierrores. Incluir pruebas automatizadas y pruebas de regresión.
• Usan revisiones técnicas efectivas como filtro previo a las pruebas. Las revisiones técnicas pueden ser tan efectivas como probar para descubrir errores.
• Realizan revisiones técnicas para valorar la estrategia de prueba y los casos de prueba. Las revisiones de prueba pueden descubrir inconsistencias, omisiones y errores evidentes en el abordaje de las pruebas.
• Desarrollan un enfoque de mejora continuo para el proceso de prueba. La estrategia de pruebas debe medirse.

Estrategia de prueba para software convencional

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. 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

Entre los potenciales errores que deben ponerse a prueba cuando se evalúa el manejo de errores están:

1. la descripción de error ininteligible,
2. el error indicado no corresponde con el error que se encuentra,
3. la condición del error causa la intervención del sistema antes de manejar el error
4. el procesamiento excepción-condición es incorrecto
5. la descripción del error no proporciona suficiente información para auxiliar en la localización de la causa del error.

Procedimiento de prueba de unidad

• Son adjuntas al paso de codificación.
• Pueden ocurrir antes o después de generar el código fuente.
• Se simplifican cuando se diseña un componente con alta cohesion.

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 programa se construye y prueba en pequeños incrementos, donde los errores son más fáciles de aislar y corregir.

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).
El proceso de integración se realiza en una serie de cinco pasos:

1. 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.
2. Dependiendo del enfoque de integración seleccionado, los representantes subordinados se sustituyen uno a la vez con componentes reales.
3. Las pruebas se llevan a cabo conforme se integra cada componente.
4. Al completar cada conjunto de pruebas, otro representante se sustituye con el componente real.
5. Las pruebas de regresión, pueden realizarse para asegurar que no se introdujeron nuevos errores.

La estrategia de integración descendente verifica los principales puntos de control o de decisión al principio en el proceso de prueba.

Integracion ascendente: La prueba de integración ascendente, como su nombre implica, comienza la construcción y la prueba con módulos atómicos. 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).

...