UNIDAD 2 - Resumen Estrategia de prueba del software

 Resumen Estrategia de prueba del software

Resumen de Estrategia de pruebas

En su inicio la ingeniería del software define su papel y analiza los requerimientos aquí se establecen los criterios de dominio, su función, comportamiento, desempeño, restricciones y validación, esto se avanza en forma de espiral hacia adentro donde tras su recorrido se llega al diseño y finalmente a la codificación. La espiral está conformada por:

• La prueba de unidad: se concentra en cada unidad que se implementa en el código fuente, se utilizan técnica de pruebas en estructuras de control de componentes asegurando su cobertura y la máxima detección de errores.
• La prueba de integración: se centra en su diseño y la construcción de la arquitectura del software se utilizan las técnicas de diseño de casos de pruebas, aunque también pruebas que ejercitan rutas de programas para asegurar la cobertura de las principales rutas de control.
• La prueba de Validación: Es una prueba de orden superior donde se validan los requerimientos establecidos como parte de su modelado, se evalúan sus criterios de validación para proporcionar garantía de que el software cumple con los requerimientos informativos, funcionales, de comportamiento y rendimiento.
• Y La prueba de sistema: También es una prueba de orden superior donde el software de cómputo se prueba totalmente verificando que todos los elementos se mezclan de manera adecuada y que se logra el funcionamientos y rendimiento global del sistema.

Estas pruebas se enfocan individualmente para garantizar que funcionan adecuadamente como unidad   

Criterios Para Completar las Pruebas

El enfoque de ingeniería de software de salas limpias sugiere que se usen técnicas estadísticas donde se ejecutan una serie de pruebas derivadas de una muestra estadística por parte de todos los usuarios de una población objetivo otros sugieren el modelado estadístico y la teoría de confiabilidad del software para predecir cuando terminan las pruebas de completarse    

aspectos estratégicos

Estos criterios son aspectos estratégicos donde una estrategia de software triunfara cuando quienes prueben el software

• Especifican los requerimientos del producto en forma cuantificable antes de comenzar con las pruebas.
• Establezcan de manera explícita y medible los objetivos específicos de las pruebas.
• Entiendan a los usuarios del software y desarrollan un perfil para cada categoría del usuario
• Desarrollan un plan de prueba con ciclos Agiles.
• Construyen un software Robusto diseñado para probarse a si mismo.
• Usen revisiones técnicas efectivas como un filtro previo a las pruebas.
• Revisiones técnicas para valorar la estrategia y casos de prueba.
• Desarrollen un enfoque de mejora continuo para el proceso de la prueba.

 

Estrategias de pruebas para software convencional.

Una estrategia de prueba se coloca entre los dos extremos tomando una visión incremental de las pruebas empezando por unidades de programas individuales avanzando las pruebas del diseño facilitando la integración y culmina con pruebas de sistema.

Prueba de unidad: Se enfoca en la lógica de procesamiento interno y de las estructuras de datos dentro de las fronteras de un componente sus esfuerzos de verificación se enfocan en la parte mas pequeña del diseño del software

Consideración

La interfaz del módulo se prueba garantizando que la información fluya de adecuadamente hacia y desde la unidad de software que se prueba.

La estructura de los Datos locales se examina asegurando que los datos temporales mantengan su integridad en la ejecución del algoritmo.

Las rutas independientes a través de la estructura de control se ejercitan asegurando los estatutos en un modulo se ejecuten al menos una vez y opere adecuadamente

Luego se ponen a prueba las rutas para el manejo de errores.

El flujo de datos a través de la interfaz de un componente se prueba antes de iniciar otra prueba, se ejercitan las estructuras de datos locales y averiguan el impacto local sobre los datos globales.

Las pruebas selectivas de las rutas se deben diseñar para descubrir errores de cálculos.

Las pruebas de frontera son importantes por la frecuencia de fallas es muy probable que los casos de pruebas que ejercitan en la estructura de datos, el flujo de control y los valores de datos se descubran errores.

Un buen diseño anticipa las condiciones de un error.

Cuando se evalúa un error se debe poner a prueba:

• Descripción del error ininteligible
• El error indicado no corresponde con el error que se encuentra
• La condición del error causa intervención del sistema antes del manejo del error
• El procesamiento es incorrecto.
•  La descripción del error no proporciona suficiente información.

Procedimientos

 

La revisión de la información proporciona una guía para establecer casos de prueba, cada caso de prueba debe acoplarse a un conjunto de resultados esperados que con frecuencia se desarrolla un controlador o de resguardo para cada prueba de unidad

Controlador: No es más que un programa principal que acepta los casos de prueba, pasa datos al componente e imprime resultados relevantes.

Representantes:   Sirven para sustituir módulos del componente que se va a probar, utiliza la interfaz modulo subordinado para realizar mínima manipulación de datos, imprimir verificación de entradas y regresar el control al módulo mediante la prueba.

 

 Pruebas de integración

Cuando los módulos se juntan puede perderse los datos mediante las interfaces y no producir su función principal

Las pruebas de integración son una técnica sistemática para construir la arquitectura del software mientras se ejecutan pruebas de errores asociados a las interfaces.  Se dice que es incremental porque el programa se construye y prueba en pequeños incrementos así los errores son mas fáciles de aislar y corregir

Estrategias descendentes: Es un enfoque incremental a la construcción de la arquitectura del software los módulos se integran hacia abajo comenzando por el modulo de control principal luego los módulos subordinados se incorporal en la estructura luego se construye las rutas de control central, derecha y la integración incorpora los componentes subordinados en cada nivel.

 

El proceso de integración se realiza en 5 pasos:

1. El módulo de control principal se usa como un controlador de prueba y los representantes se sustituyen al módulo de control principal.
2. 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.

Sus complicaciones resultan ser en la practica donde pueden surgir problemas logísticos como el procesamiento en niveles bajos en la jerarquía a fin de probar adecuadamente los niveles superiores.

Integración Ascendente:  sus módulos son integrados de abajo hacia arriba se elimina la necesidad de representantes y se puede implementar con los siguientes pasos:

• Los componentes en el nivel inferior se combinan en que realizan una subfunción de software específica.
•  Se escribe un controlador 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.

Se integra combinando los componentes para formar grupos 1 2 y 3 estos son probados por un controlador.

Prueba de regresión:  Cada que se agrega un nuevo módulo el software cambia esto puede generar problemas con las funciones entonces la prueba de regresión es la ejecución de un subconjunto de pruebas asegurando que los cambios no ocasionaron fallas se pueden realizar manual con las herramientas de captura/ reproducción permitiéndole al ingeniero capturar casos de pruebas la suite de prueba de regresión contiene tres clases de casos pruebas.

• 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:  se utiliza cuando se desarrolla el software del producto abarcando 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 se somete a prueba de humo diariamente.

El enfoque de integración puede ser descendente o ascendente.

Sus 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 ya que lo que resulta una ventaja para un tipo de estrategia resulta desventaja para la otra como, por ejemplo

La principal desventaja del enfoque descendente es la necesidad de representantes y las dificultades de prueba que pueden asociarse con ellos.

La principal desventaja de la integración ascendente es que el programa como entidad no existe hasta que se agrega el último módulo.

La mejor opción depende del tipo de software una opción sería combinar estas estrategias utilizar pruebas descendentes para niveles superiores de la estructura del programa acopladas con pruebas ascendentes para niveles subordinados.

Productos de trabajo de las pruebas de integración:  se incorpora un plan de prueba y un procedimiento de prueba y se vuelve parte de la configuración del software, la prueba de divide en fases y construcciones sus fases son las siguientes:

• Interacción con el usuario (entrada y salida de comandos, representación de despliegue, procesamiento y representación de errores)
• Procesamiento de sensores (adquisición de salida de sensor, determinación de condiciones del sensor, acciones requeridas como consecuencia de las condiciones)
• Funciones de comunicación (capacidad para comunicarse con la estación de monitoreo central)
• Procesamiento de alarma (pruebas de acciones del software que ocurren cuando se encuentra una alarma)

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

Para todo esto se establecen fechas de inicio y fin de cada fase, y una breve descripción del software , de su procedimiento de prueba, señala el orden de la integración y sus pruebas y se incluye una lista de todos los casos de pruebas y los resultados esperados