Resumen Estrategia de prueba del software

 

Resumen estrategia de prueba del software.

 Una estrategia de prueba de software proporciona una guía que describe los pasos que deben realizarse como parte de la prueba, cuando se planean y se llevan a cabo dichos pasos, y cuanto esfuerzo, tiempo y recursos se requerirán. 

para realizar un buen programa de pruebas de software, en todos se puede encontrar una estructura similar. A medida que se va creando el software (desde las primeras líneas de código), se debe empezar también a realizar pruebas; en un principio serían lo que se conoce como pruebas unitarias. Luego, cuando el software va tomando forma (a través del código) se deben comenzar a hacer las pruebas integrales; las cuales nos van a permitir detectar de forma rápida, si los diferentes módulos se están comunicando entre sí, y lo más si importante, detectar que esa comunicación se hace de manera correcta. Por último, cuando ya se tiene el software desarrollado de manera completa, se deben hacer las pruebas de orden superior, que son las que finalmente nos van a permitir sacar a producción o no, el software que se ha desarrollado.

Criterio para completar las pruebas

Las pruebas en realidad no se completan. Aunque muchos desarrolladores se basan en sistemas estadísticos para definir si las pruebas se han completado o no, lo cierto es que nunca se llega a obtener un cien por ciento. Ante este panorama tan oscuro, hay una luz de esperanza, al menos para Tom Gilb. Para él, las pruebas tienen más oportunidad de ser “completadas” si: una estrategia de software triunfara cuando quien prueban el software hacen lo siguiente:

- Se especifican los requerimientos del producto en forma cuantificable mucho antes de empezar con las pruebas.

  -Se establecen de manera explícita los objetivos de las pruebas.

 -Se entiende quienes son los usuarios del software y se desarrolla un perfil para cada categoría de usuario.

-Se desarrolla un plan de pruebas que enfatice pruebas del ciclo rápido.

-Se construye software robusto que esté diseñado para probarse a sí mismo.

 -Se usan revisiones técnicas efectivas como filtro previo a las pruebas.

 -Se realizan revisiones técnicas para valorar la estrategia de prueba y los casos de prueba.

  -Se desarrolla un enfoque de mejora continuo para el proceso de prueba.

 

 

 

 

Tipos de prueba.

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.

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.

En las pruebas de integración, podemos encontrar el tipo de pruebas de integración incrementa; el cual consiste en probar el software en pequeños trozos, de esta forma se logra un mejor control y se puede incluso hasta llegar a probar las interfaces por completo.

Tipos de prueba de integración.

Integración descendente: es un enfoque incremental a la construcción de la arquitectura de software.

El módulo de control principal se usa como un controlador de prueba y los stubs se sustituyen con todos los componentes directamente subordinados al módulo de control principal.

Dependiendo del enfoque de integración seleccionado, los stubs 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 pueden realizarse para asegurar que no se introdujeron nuevos errores.

 

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.

 Los componentes en el nivel inferior se combinan en grupos 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.

 

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.

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

Abarca las siguientes actividades:

Los componentes de software traducidos en código se integran en una construcción, la cual incluye archivos de datos, bibliotecas, módulos reutilizables y componentes sometidos a ingeniería que se requieren para implementar una o más funciones del producto.

Se diseña una serie de pruebas para exponer los errores que evitarán a la construcción realizar adecuadamente su función. La intención debe ser descubrir errores “paralizantes” que tengan la mayor probabilidad de retrasar el proyecto.

 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.

La prueba de humo trae los siguientes beneficios:

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.