Pruebas Orientadas a Objetos en Pruebas de Software

Requisito previo: prueba de software El
software generalmente se somete a muchos niveles de prueba, desde pruebas unitarias hasta pruebas de sistema o de aceptación. Por lo general, las pruebas en la unidad , las «unidades» pequeñas o los módulos del software se prueban por separado y se enfocan en probar el código de ese módulo. En pruebas de orden superior (p. ej., pruebas de aceptación ), todo el sistema (o un subsistema) se prueba con el objetivo de probar la funcionalidad o el comportamiento externo del sistema.

A medida que los sistemas de información se vuelven más complejos, el paradigma orientado a objetos gana popularidad debido a sus beneficios en análisis, diseño y codificación. Los métodos de prueba convencionales no se pueden aplicar para las clases de prueba debido a los problemas relacionados con las clases de prueba, las clases abstractas, la herencia, el enlace dinámico, el mensaje, el paso, el polimorfismo, la concurrencia, etc.
La prueba de clases es un problema fundamentalmente diferente al de la prueba de funciones. Una función (o un procedimiento) tiene un comportamiento de entrada-salida claramente definido, mientras que una clase no tiene una especificación de comportamiento de entrada-salida. Podemos probar un método de una clase usando enfoques para probar funciones, pero no podemos probar la clase usando estos
enfoques.

Según Davis, las dependencias que ocurren en los sistemas convencionales son:

• Dependencias de datos entre variables
• Dependencias de llamadas entre módulos
• Dependencias funcionales entre un módulo y la variable que calcula
• Dependencias de definición entre una variable y sus tipos.

Pero en los sistemas orientados a objetos existen las siguientes dependencias adicionales:

• Dependencias de clase a clase
• Dependencias de clase a método
• Dependencias de clase a mensaje
• Dependencias de clase a variable
• Método para dependencias variables
• Método para enviar dependencias
• Dependencias de método a método

Problemas en las clases de prueba:
por lo tanto, se requieren técnicas de prueba adicionales para probar estas dependencias. Otro tema de interés es que no es posible probar la clase dinámicamente, solo sus instancias, es decir, los objetos pueden ser probados. De manera similar, el concepto de herencia abre varios problemas, por ejemplo, si se realizan cambios en una clase principal o superclase, en un sistema más grande de una clase será difícil probar las subclases individualmente y aislar el error en una clase.

En los programas orientados a objetos, el flujo de control se caracteriza por el paso de mensajes entre objetos, y el flujo de control cambia de un objeto a otro mediante la comunicación entre objetos. En consecuencia, no hay flujo de control dentro de una clase como funciones. Esta falta de flujo de control secuencial dentro de una clase requiere diferentes enfoques para las pruebas. Además, en una función, los argumentos pasados ​​a la función con datos globales determinan la ruta de ejecución dentro del procedimiento. Pero, en un objeto, el estado asociado con el objeto también influye en la ruta de ejecución, y los métodos de una clase pueden comunicarse entre ellos a través de este estado porque este estado es persistente a través de las invocaciones de métodos. Por lo tanto, para probar objetos, el estado de un objeto tiene que desempeñar un papel importante.

Las técnicas de pruebas orientadas a objetos son las siguientes:

1. Pruebas basadas en fallas:
   este tipo de verificación permite generar casos de prueba compatibles con la especificación del consumidor o el código o ambos. Intenta identificar posibles fallas (áreas de diseño o código que pueden dar lugar a errores). Para todas estas fallas, se desarrolla un caso de prueba para «eliminar» los errores. Estas pruebas también fuerzan cada vez que se ejecuta el código.

   Este método de prueba no encuentra todos los tipos de errores. Sin embargo, se pueden pasar por alto errores de especificación e interfaz incorrectos. Estos tipos de errores se pueden descubrir mediante pruebas de función en el modelo de prueba tradicional. En el modelo orientado a objetos, los errores de interacción se pueden descubrir mediante pruebas basadas en escenarios. Esta forma de prueba orientada a objetos solo puede probar contra las especificaciones del cliente, por lo que aún se pasan por alto los errores de interfaz.

2. Pruebas de clase basadas en pruebas de métodos:
   este enfoque es el más simple para probar clases. Cada método de la clase realiza una función cohesiva bien definida y, por lo tanto, puede relacionarse con las pruebas unitarias de las técnicas de prueba tradicionales. Por lo tanto, todos los métodos de una clase pueden estar involucrados al menos una vez para probar la clase.
3. Pruebas aleatorias:
   Se apoya en el desarrollo de una secuencia de prueba aleatoria que intenta la mínima variedad de operaciones propias del comportamiento de las categorías.
4. Prueba de partición:
   esta metodología categoriza las entradas y salidas de una categoría para verificarlas severamente. Esto minimiza el número de casos que tienen que ser diseñados.
5. Pruebas basadas en escenarios:
   implica principalmente capturar las acciones del usuario y luego estimularlas a acciones similares a lo largo de la prueba.
   Estas pruebas tienden a buscar la forma de interacción del error.