1. Explique por qué las pruebas solo pueden detectar la presencia de

errores, no su ausencia.

Porque el objetivo de las pruebas es la detección de defectos en el software

(descubrir un error es el éxito de una prueba) y el descubrimiento de un

defecto significa un éxito para la mejora de la calidad. Es interesante

planificar y diseñar las pruebas para poder detectar el máximo número y

variedad de defectos con el mínimo consumo de tiempo y esfuerzo.

2. Compare una integración y pruebas ascendente y descendente

comentando sus ventajas y desventajas para pruebas arquitectónicas,

para mostrar una versión del sistema a los usuarios y para la

implementación práctica y observación de las pruebas. Explique

porqué la integración de la mayoría de los sistemas grandes, en la

práctica, tiene que usar una mezcla de aproximaciones ascendentes y

descendentes.

Ascendente DescendenteVentajas

Es un método ventajoso si aparecen grandes fallos en la parte inferior del programa, ya que se prueba antes.

La entradas para las pruebas son más fáciles de crear, puesto que los módulos inferiores tienen funciones más específicas.

Es más fácil observar los resultados de la prueba, ya que es en los módulos inferiores donde se elaboran los datos (los superiores suelen ser módulos de control).

Ventajas

Es ventajosa si aparecen grandesdefectos en los niveles superiores del programa, ya que se prueban antes.

Una vez incorporadas las funciones de entrada/salida, es fácil manejar los casos de prueba.

Permite ver antes una estructura previa del programa, lo que facilita el hacer demostraciones y ayuda a mantener la moral.

Desventajas

Se requieren módulos impulsores, que deben

Desventajas

Se requieren módulos ficticios que suelen ser complejos de

codificarse. El programa, como entidad, sólo

aparece cuando se agrega el último módulo.

crear. Antes de incorporar la

entrada/salida resulta complicado el manejo de los casos de prueba.

Las entradas para las pruebas pueden ser difíciles o imposibles de crear, puesto que, a menudo, se carece de los módulos inferiores que proporcionan los detalles de operación.

Es más difícil observar la salida, ya que los resultados surgen de los módulos inferiores.

Pueden inducir a diferir la terminación de la prueba de ciertos módulos.

Integración Descendente: Esta ataca directamente a la implementaron de

los módulos desde el programa principal hacia los módulos inferiores de

manera jerárquica. El modo de funcionamiento consiste en que el modulo

de control principal maneje toda la información de las pruebas y las

distribuya directamente a los módulos que se encuentren inmediatamente

subordinados, y a su ves estos van realizando el mismo procedimiento a

sus módulos dependientes. Hay que tener presente que las pruebas se

tienen que realizar cada ves que se va incorporando un nuevo módulo.

La estrategia descendente suena relativamente fácil, pero en la realidad

pueden producirse algunos problemas logísticos que podrían llegar a

repercutir en los resultados de nuestras pruebas, esto se refiere a, que

ocurriría si un módulo de nivel jerárquico superior depende de cálculos

realizados en un módulo de nivel inferior. El encargado de realizar la prueba

tiene tres opciones ante esta problemática:

Retrasar muchas de las pruebas hasta que se fusionen los módulos

faltantes.

Realizar resguardos que realicen funciones limitadas que simulen los

módulos reales.

Integrar el software desde el fondo de la jerarquía hacia arriba.

La primera aproximación hace que perdamos cierto control sobre la

correspondencia de ciertas pruebas especificas con la incorporación de

estos módulos y por ende el control que realicemos no será tan exacto y

acabado, además de producir incongruencia en los resultados, por ende,

dificulta la determinación de la causa del error y tiende a violar la naturaleza

altamente de restrictiva de la aproximación descendente. La segunda

aproximación es factible, pero puede llevar a un significativo incremento del

esfuerzo a medida que los resguardos se hagan mas y mas complejos.

Integración Ascendente: Las pruebas de integración ascendente, como su

nombre lo indica, consiste básicamente en tratar el módulo atómico (módulo

de nivel jerárquico mas bajo) hacia arriba. Dado que los módulos son

integrados de abajo hacia arriba, e procesamiento requerido de los módulos

subordinados siempre esta disponible y se elimina la necesidad de

resguardo.

Una estrategia de integración ascendente puede ser implementada

mediante los siguientes pasos:

Se combinan los módulos de bajo nivel en grupos que realicen una

función especifica del software.

Se escribe un conductor (Programa de control de la prueba) para

coordinar la entrada y la salida de los casos de prueba.

Se prueba el grupo.

Se eliminan los conductores y se combinan los grupos moviéndose

hacia arriba por la estructura del programa.

A medida que la integración progresa hacia arriba, disminuye la necesidad

de conductores de pruebas separados. De hecho si los niveles superiores

del programa se integran de forma descendente, se pueden reducir

sustancialmente en numero de conductores y se simplifica enormemente la

integración de grupos.

Hay muchas discusiones sobre las ventajas y desventajas de las pruebas

de integración ascendentes frente a las descendentes, pero los que

tenemos que tener claro, que se llegó a la conclusión que las ventajas de

una, son las desventajas de la otra.

La selección de un tipo de prueba de integración dependerá directamente

del software y a veces del plan del proyecto. En general el mejor

compromiso puede ser una aproximación combinada (a veces denominada

prueba sándwich) que use la descendente para los niveles superiores de la

estructura del programa junto con la ascendente para los niveles

subordinados.

A medida que progresen las pruebas de integración, el encargado debe

identificar los módulos críticos. Un módulo crítico es aquel que tiene una o

más de las siguientes características:

Esta dirigido a varios requerimientos del software.

Tiene un mayor nivel de control (Reside relativamente alto en la

estructura del programa).

Es complejo o propenso a errores.

Tiene unos requerimientos de rendimientos muy definidos

Los módulos críticos deben ser probados lo antes posible. Además las

pruebas de regresión se deben centrar en el funcionamiento de los

módulos críticos.

3. Explique porqué las pruebas de interfaz son necesarias incluso

cuando los componentes individuales han sido validados

extensamente a través de las pruebas de componentes e inspecciones

de programas.

Las pruebas de interfaces son particularmente importantes para el

desarrollo orientado a objetos y basado en componentes. Los objetos y

componentes se definen por sus interfaces y pueden ser reutilizados en

combinación con otros componentes en sistemas diferentes. Los errores de

interfaz en el componente compuesto no pueden detectarse probando los

objetos individuales o componentes. Los errores en el componente

compuesto pueden surgir debido a interacciones entre sus partes.

La prueba de interfaz de usuario verifica la interacción del usuario con el

software. El objetivo es asegurar que la interfaz tiene apropiada navegación

a través de las diferentes funcionalidades. Adicionalmente, las pruebas de

interfaz aseguran que los objetos de la interfaz a ser probada se encuentran

dentro de los estándares de la industria.

4. Indique tres situaciones en las que las pruebas de todos los caminos

independientes en un programa pueden o no detectar errores en el

programa.

1ra. Situación: Una vez determinada la cantidad de pruebas necesarias, los

datos no sean variados, no se consideren errores humanos en el ingreso de

datos. Esto daría resultados erróneos en la prueba de los caminos

independientes.

2da. Situación: En la etapa de actualización de los sistemas, las pruebas de

caminos independientes originales no tendrían la validez, ya que los

módulos adicionados o modificados podrían anular los resultados arrojados.

3ra. Situación: Una vez determinada la cantidad de pruebas necesarias, se

necesita que las pruebas se realicen con datos tomados de procesos

anteriores o de uso real.