Drivers y stubs para el testing, Diapositivas de Programación Java

¡Descarga Drivers y stubs para el testing y más Diapositivas en PDF de Programación Java solo en Docsity!

Projecte de Programació

Prueba de Programas

Prueba de Programas

La prueba de programas es el proceso de ejecución y evaluación, manual y/o automática, de un sistema informático con los siguientes objetivos:

• Eliminación de los errores de especificación, diseño e implementación
• Verificación de los requerimientos funcionales:
  • Qué funcionalidades faltan?
  • Es esto lo que el usuario quería?
• Verificación de los requerimientos no funcionales

Prueba de Programas

Detección de errores

• La EXPERIENCIA es FUNDAMENTAL
• Hay dos técnicas fundamentales:
  • Verificación formal ( program proving)
  • Verificación experimental ( program testing)

Prueba de Programas

Verificación formal

• Demostración formal de que el programa satisface la especificación
• Problemas:
  • Requiere conocimientos muy específicos, es difícil y caro
  • No garantiza la ausencia de errores de especificación
    • No siempre disponemos de la especificación formal de todos los componentes del sistema (librerías, etc.)
• Suele usarse típicamente en fragmentos críticos del sistema o en sistemas muy críticos

Estrategias de prueba

Juegos de Prueba : Subconjunto “representativo” con el que probar Un buen juego de pruebas es aquel que tiene una alta probabilidad de encontrar un error -> para escogerlo, se pueden seguir diversas estrategias Lo más usado son los métodos de “caja”: el software es

visto como una caja con entradas y salidas

Tres estrategias básicas:

• Caja blanca
• Caja negra
• Caja gris

Prueba de Programas: Program Testing

Prueba de Programas: Program Testing

Caja blanca Quien hace las pruebas (programador/analista) conoce la estructura interna del código:

• Puede forzar la ejecución al menos una vez de todas las instrucciones: condicionales, casos límite en los bucles, etc.
• Puede definir cadenas estilo “variable-instrucciones donde

aparece” ( dataflow) -> hay que ir a buscar los casos

límite , asegurándose de que los casos representativos funcionan

• Normalmente se usa sólo a nivel de pruebas de componentes específicos

Caja gris Mezcla de los dos estrategias anteriores. Quien hace las pruebas conoce la estructura interna del código:

• Las pruebas se hacen en modo caja negra: se generan las entradas y se comprueba que las salidas son las que corresponden
• Las entradas y salidas pueden ser más precisas, pues pueden obligar al código a pasar por donde interese
• Se pueden focalizar las entradas en los puntos críticos

Prueba de Programas: Program Testing

En OOP tendremos varios niveles de pruebas:

• Pruebas de componentes: pruebas de (los métodos de) las clases aisladamente
• Pruebas de integración: pruebas de les interacciones entre componentes. Probamos conjuntos de clases, posiblemente agrupados por casos de uso o funcionalidad
• Pruebas del sistema: pruebas del programa como un todo
• Pruebas de integración del sistema: el programa puede no estar solo, sino formar parte de un sistema más grande, en el que haya otros programas

Prueba de Programas: Program Testing

Pruebas de componentes: Drivers y Stubs

Prueba de Programas: Program Testing

Pruebas de componentes: Drivers y Stubs

• Para cada clase a probar tenemos que tener un driver. Los

stubs sólo han de estar si se necesitan

• En teoría: aunque tengamos la clase B probada, si estamos

probando una clase A que usa la clase B, hay que usar un

stub para probar la clase A (si no, no podremos asegurar

completamente que el error esté en la clase A).

• En el caso de la prueba de clases abstractas, hay que

implementar una subclase stub con la implementación de los

métodos abstractos. Eso permite crear instancias del stub y

poder probar los métodos de la clase abstracta que sí están

implementados (vía un driver y eventualmente otros stubs)

Prueba de Programas: Program Testing

Pruebas de componentes: Drivers y Stubs

El driver tendría la siguiente especificación: public class DriverClaseA { public void testConstructor(); public void testGetAtrib1(); public void testGetAtrib2(); public void testGetCalculoAtrib2(); public static void main (String [] args); }

Es decir, un testMétodo por cada Método, que nos permita

probar que el método hace lo que se espera de él -> recordar estrategias de prueba…

Prueba de Programas: Program Testing

Pruebas de componentes: Drivers y Stubs

Para acabar nos haría falta un stub para la clase B, con la

siguiente especificación: public class ClaseB { public int calculoComplejo(); } Es decir, se define un método por cada método de ClaseB que se usa en ClaseA. La implementación ha de ser trivial:

• retornar un valor fijo o random del tipo de retorno return 42;
• escribir un mensaje de paso por el método System.out.println(“llamada método X con parám Y”);
• …

Prueba de Programas: Program Testing

Pruebas de integración: Enfoques

• Bottom-Up
  • Las clases de nivel más bajo son las primeras que se prueban
  • El programa no se prueba hasta el final
• Top-Down
  • Las clases de nivel más bajo son las últimas que se prueban
  • Necesitamos tener el programa completo desde el principio
• Híbridos ( Sandwich Testing)

Prueba de Programas: Program Testing

Pruebas de integración: Enfoque Híbrido

• Híbridos ( Sandwich Testing)
  • Mezcla de top-down y bottom-up
  • Permite empezar a probar por las clases más críticas
  • Permite desarrollar el programa de forma más flexible

Es el más adecuado para las pruebas de integración de PROP

Prueba de Programas: Program Testing