Este documento presenta una práctica sobre técnicas de pruebas de software en un contexto de orientado a objetos. Incluye preguntas sobre por qué las clases son la unidad más pequeña para probar, la importancia de comenzar las pruebas con el análisis y diseño orientado a objetos, y por qué es necesario volver a probar las subclases.
0 calificaciones0% encontró este documento útil (0 votos)
17 vistas5 páginas
Este documento presenta una práctica sobre técnicas de pruebas de software en un contexto de orientado a objetos. Incluye preguntas sobre por qué las clases son la unidad más pequeña para probar, la importancia de comenzar las pruebas con el análisis y diseño orientado a objetos, y por qué es necesario volver a probar las subclases.
Título original
Práctica 10 - Técnicas de Pruebas del Software (Parte II)
Este documento presenta una práctica sobre técnicas de pruebas de software en un contexto de orientado a objetos. Incluye preguntas sobre por qué las clases son la unidad más pequeña para probar, la importancia de comenzar las pruebas con el análisis y diseño orientado a objetos, y por qué es necesario volver a probar las subclases.
Este documento presenta una práctica sobre técnicas de pruebas de software en un contexto de orientado a objetos. Incluye preguntas sobre por qué las clases son la unidad más pequeña para probar, la importancia de comenzar las pruebas con el análisis y diseño orientado a objetos, y por qué es necesario volver a probar las subclases.
Descargue como PDF, TXT o lea en línea desde Scribd
Descargar como pdf o txt
Está en la página 1/ 5
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.
