1. En las pruebas de unidad en el contexto Orientado a Objetos, es posible
probar una sola operacin en aislamiento (F) Explicacin: En las pruebas de unidad en el contexto Orientado a Objetos, no es posible probar una sola operacin en aislamiento, sino como parte de una clase. (Un mtodo implementado en una superclase es usado por sus subclases pero aplicado en el contexto de ellas). (Cap 17 Pag 398) 2. Cuales niveles de prueba son distintos para software orientado a objetos a. Unidad Y Validacin b. Integridad Y Validacin c. Unidad y Sistema d. Validacin y Sistema e. Ninguna de las anteriores
software convencional y
Explicacin: Los niveles de pruebas en los que se presenta una
distincin para software convencional y orientado a objetos son unidad y validacin debido a la encapsulacin y la herencia del SW OO. (Cap 17 pag 399) 3. En relacin a que se deben probar todos los modelos orientados a objetos dentro del contexto de la sintaxis, semntica, y la pragmtica del modelo. a. Exactitud, completitud y observabilidad. b. Estabilidad, comprensibilidad y consistencia c. Consistencia, exactitud y completitud d. Consistencia, estabilidad y completitud e. Ninguna de las anteriores Explicacin: Todos los modelos OO deben probarse en relacin con su exactitud, completitud y consistencia dentro del contexto de la sintaxis, la semntica y la pragmtica del modelo. (Cap 19 pag 439) 4. Cul es la unidad comprobable ms pequea en las pruebas de unidad en el contexto orientado a objetos a. Mdulo b. Clase Encapsulada c. Componente d. Subrutina e. Ninguna de las anteriores Explicacin: La unidad comprobable ms pequea en las pruebas de unidad en el contexto orientado a objetos es la clase encapsulada (Cap 19 pag 441)
5. No son caractersticas de las pruebas basadas en hebra o hilo
(seleccione 3) a. Es una estrategia para la prueba de unidad de los sistemas OO. b. Integra el conjunto de clases necesarias para dar respuesta a una entrada o evento del sistema. c. Cada hebra se integra y se prueba de forma individual. d. Comienza con las clases independientes y luego las clases dependientes. e. Es una estrategia para la prueba de integracin de los sistemas OO. f. Se prueban un conjunto de hebras y se prueban en conjunto. Explicacin: estrategia para la prueba de integracin de los sistemas OO. Integra el conjunto de clases requeridas para responder a una entrada o evento para el sistema. Cada hebra se integra y se prueba de manera individual, y posteriormente se aplican pruebas de regresin. (Cap 19 pag 442) 6. La prueba de estructura profunda se disea para ejercitar dependencias, comportamientos y mecanismos de comunicacin que se establezcan como parte del modelo de diseo para el software convencional (F). Explicacin: La prueba de estructura profunda se disea para ejercitar dependencias, comportamientos y mecanismos de comunicacin que se establezcan como parte del modelo de diseo para el software orientado a objetos (Cap 19 pag 442) 7. Si en una clase se define una serie de mtodos, y estos son heredados y/o redefinidos en otras clases (hijas), se debe probar: a. Los mtodos implementados en la clase padre b. Los mtodos implementados en la clase padre y aquellos redefinidos en las clases hijas. c. Solo aquellos mtodos redefinidos en la clase hija. d. Todos los mtodos tanto en la clase padre como en las clases hijas. e. Ninguna de las anteriores. Explicacin: Si en una clase se define una serie de mtodos, y estos son heredados y/o redefinido en otras clases (hijas) para servir en un contexto local, dichos mtodos se deben probar ya que si el mtodo es redefinido representa un nuevo diseo y un nuevo cdigo. Los mtodos no redefinidos tambin deben probarse ya que pueden manejar mal el nuevo comportamiento. Por tanto, necesita nuevas pruebas aun cuando el diseo y el cdigo no hayan cambiado. No obstante, es importante observar que es posible que slo se ejecute un subconjunto de todas las pruebas para estos mtodos (Aquellos que no dependen directamente de mtodos redefinidos no necesitan probarse exhaustivamente en las clases que los heredaron). (Cap 19 pag 442)