Barly Eduardo Espinal 

Matricula 

2017‐4928 

Periodo académico 

2019‐2 

Nombre del profesor 

Ing. Leandro Fondeur 

Nombre del tema de estudio 

Práctica 9 ‐ Técnicas de prueba del Software II 

 
 

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 el software orientado a objetos, el concepto de unidad cambia. La

definición de clases y objetos. Esto significa que cada clase y cada instancia de una clase
(objeto), envuelven a los atributos (datos) y operaciones (también conocidos como
métodos o servicios), que manipulan estos datos. ¿Por qué la "prueba” debe comenzar
con el análisis y el diseño orientado a objetos? En lugar de probar un módulo individual,
la unidad comprobable más pequeña es la clase encapsulada. Puesto que una clase puede
contener algunas operaciones diferentes y una operación particular puede existir como
parte de un número de clases diferentes, el significado de prueba de unidad cambia
dramáticamente.

En la visión tradicional de la prueba de unidad ya no es posible probar una sola operación

aislada ejemplo: tenemos una superclase que la heredan otras subclases, cada subclase
usa los métodos que se encuentran en la superclase, pero se aplica dentro del contexto de
los atributos y operaciones privadas que se definieron en cada subclase y esto puede
llevar a que tengan distintos comportamientos, aunque sean sutiles y basándonos en esto
es necesario hacer pruebas en el contexto de cada subclase

2. ¿Por qué la "prueba” debe comenzar con el análisis y el diseño orientado a objetos?

La construcción de software orientado a objetos comienza con la creación de modelos de

requerimientos (análisis) y de diseño.1 Debido a la naturaleza evolutiva del paradigma de
ingeniería del software OO, dichos modelos comienzan como representaciones
relativamente informales de los requisitos de sistema y evolucionan hacia modelos
detallados de clases, relaciones de clase, diseño y asignación de sistema, y diseño de
objetos (que incorpora un modelo de conectividad de objetos mediante mensajería). En
cada etapa, los modelos pueden “probarse” con la intención de descubrir errores
previamente a su propagación hacia la siguiente iteración.

Puede argumentarse que la revisión de los modelos de análisis y de diseño OO es

especialmente útil, pues los mismos constructos semánticos (por ejemplo, clases,
atributos, operaciones, mensajes) aparecen en los niveles de análisis, diseño y código. Por
tanto, un problema en la definición de los atributos de clase que se descubra durante el
análisis soslayará los efectos colaterales que puedan ocurrir si el problema no se
descubriera hasta el diseño o el código (o incluso en la siguiente iteración de análisis).
3. ¿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.

Si es necesario, debido a que no se puede probar más de una operación a la vez (la visión
convencional de la unidad de prueba), pero sí como parte de una clase. La prueba de
clases para el software OO es el equivalente de las pruebas de unidad para el software
convencional. A 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 datos que fluyen a
través de la interfaz del 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.

4. ¿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?

Existen dos diferentes estrategias para la prueba de integración de los sistemas OO:

1- La prueba basada en hebra o hilos, integra el conjunto de clases requeridas para

responder a una entrada o evento del sistema. Cada hebra se integra y prueba de
manera individual. La prueba de regresión se aplica para asegurar que no ocurran
efectos colaterales.
2- La prueba basada en uso, comienza la construcción del sistema al probar aquellas
clases (llamadas independientes) que usan muy pocas clases de servidor (si es que
emplean alguna). Después de probar las clases independientes, se examina la
siguiente capa de clases que usan las clases independientes, llamadas
dependientes.
Diferencia:
La prueba basada en hebra o hilos es donde se identifica un conjunto de clases que
realizan una determinada función. La prueba basada en uso identifica desde ya lo que son
las clases independientes que son llamadas a ellas no dependen de otras.
La prueba de grupo es un paso en la prueba de integración del software OO. En ella, se
ejercita un grupo de clases colaboradoras (determinadas al examinar el CRC y el modelo
objeto-relación) al diseñar casos de prueba que intentan descubrir errores en las
colaboraciones.

5. La compatibilidad es una importante dimensión de la calidad. ¿Qué debe probarse

para garantizar que existe compatibilidad para una webapp?

La compatibilidad se prueba al ejecutar la webapp en varias configuraciones anfitrión,

tanto en el cliente como en el servidor. La intención es encontrar errores que sean
específicos de una configuración anfitrión única.
6. ¿Cuáles errores tienden a ser más serios: los que hay en el lado cliente o los del lado
servidor? ¿Por qué?

Normalmente los del servidor porque aparte de poder tener brechas de seguridad y
acarrear problemas de rendimiento afectan a todos los clientes a nivel global. En cambio,
los errores en la parte del cliente no provocan problemas de seguridad ni a nivel global y
lo más probable es que no afecte a la totalidad de los usuarios. Molesta, pero no es
peligroso.

Pero los errores del lado del cliente, aunque pueden ser hasta gramaticales, es decir pocos
significativos hay casos en los que los errores pueden ser bastante serios en el servicio
dado al cliente y estos pueden llevar al cliente a elegir otro servicio.

7. ¿Cuál es la diferencia entre prueba de carga y prueba de esfuerzo?

la prueba de carga examina la carga del mundo real en varios niveles de carga y en
varias combinaciones, y la prueba de esfuerzo fuerza a aumentar la carga hasta el punto
de rompimiento para determinar cuánta capacidad puede manejar el entorno de la
webapp.

8. ¿Existen algunas situaciones en las que la prueba de webapps deba descartarse por
completo?

Desde mi punto de vista no, ya que las pruebas existen para asegurar la calidad del
producto y con esta viene de la mano un gran grupo de ventajas como son: reducción de
tiempo empleado en encontrar defectos, simplemente con esta ventaja tenemos muchas
razones para aplicar las pruebas, clientes más satisfechos, una webapp más robusta,
conocimiento de cuáles son los limites operacionales de la webapp, entre muchísimos
otros.

9. Con sus palabras, analice los objetivos de las pruebas en un contexto webapp.

Los objetivos especificados de las pruebas pueden enunciarse en términos medible, por
ejemplo, la efectividad de las pruebas, su cobertura, el tiempo medio antes de aparecer
una falla, el costo por descubrir y corregir defectos. La densidad de defectos restantes o la
frecuencia de ocurrencia, y las horas de trabajo de prueba deben enunciarse dentro del
plan de la prueba. Entienden a los usuarios del software y desarrollan un perfil para cada
categoría del usuario. Los casos de uso que describen el escenario de interacción para
cada clase de usuario pueden reducir el esfuerzo de prueba global al enfocar las pruebas
en el uso real del producto, etc.
10. ¿Siempre es necesario desarrollar un plan de prueba escrito formalmente?
Explique.

Escrito formalmente no, pero debe de existir un plan de prueba, aunque sea escrito en un
archivo de texto plano que contenga los requerimientos por escrito, mensurables para el
producto en el que se asegure cada componente.

11. ¿Cuál es la diferencia entre probar la sintaxis de navegación y probar la semántica

de navegación?

La usabilidad se prueba para asegurar que la interfaz soporta a cada categoría de usuario
y que puede aprender y aplicar toda la sintaxis y semántica de navegación requerida.

La navegabilidad se prueba para asegurar que toda la sintaxis y la semántica de

navegación se ejecutan para descubrir cualquier error de navegación (por ejemplo,
vínculos muertos, inadecuados y erróneos).

La prueba de sintaxis de navegación

Los mecanismos de navegación se prueban para asegurarse de que cada interfaz realiza la
función que se le ha encargado. Splaine y Jaskiel sugieren que debe probarse cada uno de
los siguientes mecanismos de navegación:

• Vínculos de navegación: estos mecanismos incluyen vínculos internos dentro de la

webapp, vínculos externos hacia otras webapps y anclas dentro de una página web
específica. Cada vínculo debe ser probado para asegurarse de que se alcanza el contenido
o funcionalidad adecuados cuando se elige el vínculo.

• Redirecciones: estos vínculos entran en juego cuando un usuario solicita una URL
inexistente o cuando selecciona un vínculo cuyo contenido se removió o cuyo nombre
cambió. Se despliega un mensaje para el usuario y la navegación se redirige hacia otra
página (por ejemplo, la página de inicio). Los redireccionamientos deben probarse al
solicitar vínculos internos incorrectos o URL externas y debe valorarse cómo maneja la
webapp estas solicitudes.

• Marcas de página (favoritos, bookmarks): aunque las marcas de página son función del
navegador, la webapp debe probarse para garantizar la extracción de un título de página
significativo conforme se crea la marca.

• Marcos y framesets: cada marco incluye el contenido de una página web específica; un
frameset contiene múltiples marcos y habilita el despliegue de múltiples páginas web al
mismo tiempo. Puesto que es posible anidar marcos y framesets unos dentro de otros,
estos mecanismos de navegación y despliegue deben probarse para que tengan el
 contenido correcto, la plantilla y tamaño adecuados, rendimiento de descargas y
compatibilidad de navegador.

La prueba de semántica de navegación

una unidad semántica de navegación (USN) se define como “un conjunto de estructuras
de información y navegación relacionada que colaboran en el cumplimiento de un
subconjunto de requerimientos de usuario relacionados” [Cac02]. Cada USN se define
mediante un conjunto de trayectorias de navegación (llamadas “rutas de navegación”)
que conectan los nodos de navegación (por ejemplo, páginas web, objetos de contenido o
funcionalidad). Considerado como un todo, cada USN permite a un usuario lograr
requerimientos específicos definidos por uno o más casos de uso para una categoría de
usuario. La prueba de navegación ejercita cada USN para asegurarse de que dichos
requerimientos pueden lograrse

Diferencias

La prueba semántica que evalúa cuán bien el diseño se ocupa de los usuarios, ofreciendo
una dirección clara, manteniendo consistencia de lenguaje y enfoque. La prueba de
sintaxis se encarga de que cada mecanismo de navegación se prueba: vínculos
navegación, redirigir (destinos removidos), mapas de sitio, motores de búsqueda.

12. ¿Cuál es el objetivo de la prueba de seguridad? ¿Quién realiza esta prueba?

La seguridad se prueba al valorar las vulnerabilidades potenciales e intenta explotar cada

una. Cualquier intento de penetración exitoso se estima como un fallo de seguridad.

El diseño real de las pruebas de seguridad requiere conocimiento profundo del trabajo
interno de cada elemento de seguridad y amplia comprensión de una gran gama de
tecnologías de redes. En muchos casos, la prueba de seguridad se subcontrata con firmas
que se especializan en dichas tecnologías.