ESTRATEGIAS DE PRUEBA DEL

SOFTWARE.
la Estrategia proporciona la descripció n de los pasos que hay que llevar a cabo como
parte de la prueba, cuá ndo se deben planificar y realizar esos pasos, y cuá nto
esfuerzo, tiempo y recursos se van a requerir.
una estrategia de prueba contiene:

 Planificació n de la prueba
 Diseñ o de casos de prueba
 Ejecució n de las pruebas
 Agrupació n y evaluació n de datos
 ENFOQUE ESTRATÉGICO PARA LAS PRUEBAS DEL SOFTWARE
las pruebas son un conjunto de actividades que se pueden
planificar por adelantado y llevar a cabo sistemá ticamente. por esta razó n, se define
una plantilla para las pruebas del software.
El software tiene las siguientes características generales:
 la prueba la lleva a cabo el responsable del desarrollo del software y
(para grandes proyectos) un grupo independiente de pruebas.
 las pruebas comienzan a nivel de mó dulo (en los sistemas orientados a
objetos,
las pruebas empiezan a nivel de clase o de objeto) y trabajan “hacia fuera”,
hacia la integració n de todo el sistema.
 ORGANIZACIÓN PARA LAS PRUEBAS DEL SOFTWARE

Toda prueba de software debe tener la coordinació n de actividades:

el responsable del desarrollo del software siempre es responsable de probar las unidades individuales
(mó dulos) del programa, asegurá ndose de que la una lleva a cabo la funció n para la que fue diseñ ada.

los mismos programadores tienen un gran interés en demostrar que el programa está libre de errores,
que funciona de acuerdo con las especificaciones del cliente y que estará listo de acuerdo con los
plazos y el presupuesto.

GRUPO INDEPENDIENTE DE PRUEBA(GIP)

Este grupo tiene como objetivo identificar y encontrar errores. Este grupo trabaja
conjuntamente con el responsable del desarrollo de software para asegurar que se
realizan pruebas exhaustivas. Mientras se realiza la prueba, el desarrollador debe estar
disponible para corregir los errores que se van descubriendo.
los niveles de la estrategia para la prueba del software se pueden ver en el siguiente grafico:
 PRUEBA DE UNIDAD
El proceso de verificació n, se centra en la menor unidad del diseñ o del software: el
mó dulo.
está orientada a caja blanca y este paso se puede llevar a cabo en paralelo para
mú ltiples mó dulos. las pruebas que se dan como parte de la prueba de unidad son:
 PRUEBA DE INTEGRACIÓN DEL SISTEMA
La prueba de integració n es una té cnica para construir la estructura del programa
mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores
asociados con la interacció n.

INTEGRACION DESCENDENTE
Es una estrategia de integració n a la construcció n de la estructura de programas, en
cual se integran los modulos moviéndose en direcció n hacia abajo por la jerarquía de
control comenzando por el modulo principal

INTEGRACION ASCENDENTE
Empieza la construcció n y la prueba con 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 siempre está disponible y se elimina la
necesidad de resguardos.
 PRUEBA DE REGRESIÓN

La prueba de regresió n consiste en volver a ejecutar un subconjunto de pruebas que se

han llevado a cabo anteriormente para asegurarse de que los cambios no han
propagado efectos colaterales no deseados. La prueba de regresió n es la actividad que
ayuda a asegurar que los cambios no introducen un comportamiento no deseado o
errores adicionales.
PRUEBA DE HUMO
Esta prueba es utilizada cuando se ha desarrollado un producto software
“empaquetado”. Es diseñ ado como un mecanismo para proyectos críticos por tiempo,
permitiendo que el equipo de software valore su proyecto sobre una base só lida.
La prueba de humo facilita una serie de beneficios cuando se aplica sobre proyectos de
ingeniería de software complejos y críticos por su duració n:
 Se minimiza los riesgos de integració n.
 Se perfecciona la calidad del producto final.
 Se simplifican el diagnó stico y la correcció n de errores.
 El progreso es fá cil de observar
 PRUEBA DE VALIDACIÓN
La validació n se consigue cuando el software funciona de acuerdo con las expectativas
razonables del cliente. La validació n del software se consigue mediante una serie de
pruebas de caja negra que demuestran la conformidad con los requisitos.
 DEPURACIÓN
La depuració n ocurre como consecuencia de una prueba efectiva. Cuando un caso de
prueba descubre un error, la depuració n es el proceso que provoca la eliminació n del
error.
1. Se encuentra la causa,
se corrige y se elimina.

2. No se encuentra la
causa.

3. La depuració n tiene el
objetivo primordial de
encontrar y corregir la
causa de un error en el
software.
 MÉTRICAS TÉCNICAS DEL SOFTWARE
Las métricas técnicas para el software proporcionan una manera sistemá tica de
valorar la calidad basá ndose en un conjunto de reglas. También proporcionan al
ingeniero del software descubrir y corregir problemas potenciales antes de que se
conviertan en defectos catastró ficos.
Factores de calidad
 MÉTRICAS DEL MODELO DEL SOFTWARE

En esta fase, las métricas técnicas proporcionan una visió n interna a la calidad del
modelo de aná lisis. Estas métricas examinan el modelo de aná lisis con la intenció n de
predecir el "tamañ o" del sistema resultante; es probable que el tamañ o y la
complejidad del diseñ o estén directamente relacionados.