Práctica 8 - Técnicas de prueba del Software (Parte 2)

Instituto tecnológico de las américas (ITLA)

[pic 1]

Nombre: Angel María Pérez

Período: 2019-C2

Materia: Ingeniería de software

Tema: Práctica 8 - Técnicas de prueba del Software (Parte 2)

Profesor: Ing. Leandro Fondeur

Fecha: 15/07/2019

1. Con sus palabras, describa por qué la clase es la unidad razonable más pequeña para probar dentro de un sistema OO.
   Cuando se considera un programa orientado a objetos, pues el concepto que tenemos de unidad cambia. Se puede decir que la definición de clases y objetos. Esto puede significar que cada una de las clases y cada instancia de las clases, envuelven a los datos y métodos, que manipulan estos datos.

Probar un módulo individual, la unidad más pequeña comprobable es la clase u objeto encerrado. "a que una clase puede contener un número de operaciones diferentes, y una operación particular debe existir como parte de un número de clases diferentes, el significado de la unidad de prueba cambia drásticamente.

No podemos probar más de una operación a la vez, pero si como parte de una clase. La prueba de las clases para el software OO es el igual de las pruebas de unidad para el software normal. Encontramos la diferencia de las pruebas de unidad del software convencional que tienden a centrarse en el detalle algorítmico de un módulo y de los atributos que pasan a través de la interfaz de un módulo, la prueba de clases para el software OO se conduce mediante las operaciones encapsuladas por la clase y el comportamiento de la clase.

Ya que el software orientado a objetos no tiene una estructura de control  jerárquico, las estrategias convencionales de integración descendente (top*down) y ascendente (bottom*up) tienen muy poco significado. En suma, la integración de operaciones una por una en una clase (la aproximación de la integración incremental convencional), a menudo es imposible por la interacción directa e indirecta de los componentes que conforman la clase.

1. ¿Por qué la "prueba” debe comenzar con el análisis y el diseño orientado a objetos?
   Porque pueden proporcionar algunos escenarios en donde tienen una alta probabilidad de descubrir errores en los requerimientos de interacción con el usuario. Ayuda a crear las ideas básicas de los errores que podrían ocurrir, podríamos usar el método de caja blanca o caja negra. También las técnicas de ruta básica, prueba de bucle o flujo de datos pueden ayudar a garantizar que se probaron todos los enunciados en una operación.
   
2. ¿Por qué es necesario volver a probar las subclases que se instancian a partir de una clase existente si ésta ya se probó ampliamente? ¿Puede usarse el diseño de casos de prueba para la clase existente? Justifique su respuesta.

Porque si derivamos alguna acción de la clase padre pues tiene que probarse porque representa un nuevo diseño y un nuevo código, tendrá un nuevo comportamiento en la clase hija, esto sería el caso para un método que será sobre-escrito. Pero si creamos una herencia de clase padre y clase hija en donde no derivamos un X método pues ese método no tiene que probarse. Depende del uso que le demos a la acción que derivemos, dependiendo de ello pues se deduce si probarla o no.

No, es necesario derivar nuevas pruebas para la clase hija (de esa acción que derivamos de la clase padre), porque habíamos dicho que obtendrá un diseño nuevo. Además de que la clase padre y clase hija tienen diferentes diseños.

1. ¿Cuál es la diferencia entre las estrategias basadas en hebra y basadas en uso para la prueba de integración? ¿Cómo encaja la prueba de grupo?
   Basada en hebra
   Integra el conjunto de clases requeridas para responder a una entrada o evento para el sistema. Cada hebra se integra y prueba de manera individual la prueba de regresión se aplica para asegurar que no ocurran efectos colaterales.
   
   Basada en uso
   Comienza la construcción del sistema al probar dichas clases (llamadas clases independientes) que usan muy pocas clases servidor (si es que usan algunas). Después de probar las clases independientes, se prueba la siguiente capa de clases llamadas dependientes, que usan las clases independientes. Esta secuencia de probar capas de clases dependientes continua hasta que se construye todo el sistema.
   
   Bueno, la prueba de grupo es un paso en la prueba de integración del software OO. Aquí, un grupo de clases colaboradoras (determinadas al examinar el CRC y el modelo objeto relacional) se ejercita al diseñar casos de prueba que intente descubrir errores en las colaboraciones.
2. La compatibilidad es una importante dimensión de la calidad. ¿Qué debe probarse para garantizar que existe compatibilidad para una webapp?

Se prueba al ejecutar la webapp en las configuraciones que tiene anfitrión, tanto para el cliente como para el usuario. La idea es buscar errores que sea específicos de una configuración anfitriona única.

La webapp se implanta en varias configuraciones de algunos entornos diferentes y se prueba para asegurar la compatibilidad con cada configuración. Se tratan estos componentes:
1-Hardware
2-Sistemas operativos
3-Software navegador
4-Componentes de interfaz de usuario
5-Conectividad

1. ¿Cuáles errores tienden a ser más serios: los que hay en el lado cliente o los del lado servidor? ¿Por qué?

Por lo general los del servidor porque aparte de poder tener brechas con la seguridad y traer problemas con rendimiento afectan a todos los clientes que estén usando el software. En cambio, los errores por el lado del cliente no traen problemas de seguridad ni a nivel global y lo más probable es que ni afecte a la totalidad de los usuarios.

...