Decanato de Ingeniería e Informática

Escuela de Informática

Práctica 10 - Técnicas de Pruebas del Software (Parte II)

Presentado por:
Jorge Thomas Almanzar Soriano | A00110435
Omar Aldrielly Bautista Baez | A00110813
Eddy Anthony Brito Rivera | A00101811
Andrés Araujo De León | A00109382
José Miguel Almánzar | A00110652

Asignatura:
ISO300 | Fundamentos a la Ingeniería de Software

Maestro:
Ing. Leandro Fondeur

Fecha de entrega:
24 de noviembre 2022
1. Con sus palabras, describa por qué la clase es la unidad razonable más pequeña para probar dentro
de un sistema OO.
A diferencia de las pruebas en un sistema normal, donde analizamos un módulo por separado, en OO
se empieza desde una clase en específico. Eso se debe a que una clase se puede definir como una
extensión del código que funciona para encontrar un dato con base a otro que se recibe desde el
método principal. Con esto en mente, se afirma que una clase toma la misma función que un módulo a
pesar de ser más complejo, y esto se debe a su vinculación tan directa con los elementos que conforman
la clase.

2. ¿Por qué la "prueba” debe comenzar con el análisis y el diseño orientado a objetos?
En el panorama OO las estrategias tradicionales no funcionan. El programa se vuelve más complejo en
estas circunstancias, por lo que se hace difícil analizar una sola unidad sin comprometer el mismo. Al
probar el software en OO, nos da una idea de los posibles errores que sucederán en el programa de
manera individual en las clases, ya que todo está vinculado, un mal dato puede ocasionar problemas en
las demás clases

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.

Cada clase o subclase dentro de un sistema OO (Orientado a objetos) deben de probarse las mismas
pruebas a todas las unidades; De manera individual, pruebas de integración. Se aplican pruebas de
regresión para conocer los efectos colaterales por motivo de haber añadido nuevas unidades (clases).

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?

En la prueba basada en hebra se compone por las clases requeridas para realizar una función o
evento. Cada hebra se integra y se prueba de manera individual. En la prueba basada de integración
se prueban las clases que son independientes porque no son muy requeridas por otras clases ni
requieren de otras clases, y luego las clases dependientes. La prueba de grupo, en esta prueba se
ejercitan las clases colaboradoras al tratar de 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?

Ejecutar la webapp en varias configuraciones anfitrión, tanto en el cliente como en el servidor. Con la
intención de 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 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 mas probable es que no afecte a
la totalidad de los usuarios.

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

La diferencia es que la prueba de carga determina como va a responder la webapps y su entorno del
lado del servidor, y también se utiliza para valorar la velocidad de conexión de la webapps, en cambio
la prueba de esfuerzo comprende de mejor manera como falla el sistema a medida que es forzado más
allá de sus límites, la prueba de esfuerzo es una continuación de la prueba de carga.

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

No, porque sería un error grave, ya que a partir de las pruebas de webapps se asegura de que el
producto posea una alta calidad, ya cada una de las pruebas de webbapp son importantes tanto pruebas
de navegación, semántica, de seguridad entre otras, ya que facilitan el descubrimiento de errores en la
webapp, por lo que es imprensidible el uso estas pruebas y no se debe obviar o descartar estas pruebas.

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

El objetivo de la pruebas de la web App es facilitar el descubrimiento de errores o descubrir conflictos

que puede afectar a la calidad de la webapps, además enfocándose en varios aspectos de una webapp
como: estructura, función, usabilidad, compatibilidad, interacción. A medida que se diseña se aplican
cada una de las pruebas y también después que se diseña.

10. ¿Siempre es necesario desarrollar un plan de prueba escrito formalmente? Explique.

La documentación es fundamental en el campo de la ingeniería de software para el desarrollo exitoso

de un software de calidad y es necesario documentar todos los procesos realizados, no solo cuando no
estamos hablando de pruebas, sino en todos los pasos del desarrollo en sí. Ya que, cuando sea necesaria
un mantenimiento saber cómo se debe hacer.
11. ¿Cuál es la diferencia entre probar la sintaxis de navegación y probar la semántica de navegación?

Se diferencian en que la sintaxis de prueba se refiere a la prueba la navegación son enlaces de

navegación, redireccionamientos, marcadores, marcos y conjuntos de marcos, mapas de sitios y un
motor de búsqueda interno para garantizar cada interfaz realiza la funcionalidad que se le ha asignado,
pero la semántica de prueba es donde la prueba de navegación se encarga de ejecutar cada USN (unidad
semántica navegación) para asegurarse de que permiten al usuario lograr el objetivo solicitado que fue
definido por uno o más casos de uso para una clase de usuarios.

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

El propósito es evitar el robo o el secuestro de datos o códigos en las aplicaciones web. Estas pruebas
están diseñadas para detectar vulnerabilidades en el entorno del cliente, la comunicación de red que se
produce cuando los datos pasan del cliente al servidor, y viceversa, así como entornos del lado del
servidor. Cada uno de estos dominios puede ser atacado, y es los inspectores de seguridad tienen la
tarea de encontrar debilidades que podrían ser aprovechadas.