UNIVERSIDAD TECNOLGICA DE PANAM FACULTAD DE INGENIERA DE SISTEMAS COMPUTACIONALES DEPARTAMENTO DE INGENIERA DE SOFTWARE INGENIERA DE SOFTWARE II PRUEBAS DE SOFTWARE CAPTULO

8 10 EJERCIOS ESTUDIANTE: GOOD LUIS LUIS NAYSI SAMANIEGO RAL PROFESORA: ANA GLORIA CORDERO DE HERNNDEZ M.SC. GRUPOS: 1IL132 FECHA DE ENTREGA: 13 DE OCTUBRE DE 2011 II SEMESTRE, 2011

Ejercicios Prcticos Captulo 8

8.1. Explique por qu no es necesario que un programa est completamente libre de defectos antes de entregarse a sus clientes. R= No es necesario que est libre de defectos ya que al realizar las pruebas, sobre todo las pruebas de defectos, algunas de stas son las que nos demostrarn que el programa cumple con sus requerimientos. A parte no se puede demostrar que el software est en su totalidad libre de defectos o que se comporte como hayamos especificado en X circunstancia. Siempre es posible que una prueba que demos por alto descubra ms problemas en el sistema. Las pruebas pueden mostrar slo la presencia de errores, mas no su ausencia. 8.2. Indique por qu las pruebas slo pueden detectar la presencia de errores, pero no su ausencia.
R= Como sabemos, las pruebas es el proceso de establecer la existencia de errores en el programa, y su depuracin es el proceso de localizar dnde se produjeron esos errores y corregir el cdigo incorrecto. Es muy importante comprender que la prueba nunca demuestra que un programa es correcto. Siempre es posible que existan errores aun despus de la prueba ms completa. La prueba de programas slo puede demostrar la presencia de errores en un programa, no su ausencia, se considera prueba acertada aquella que establece la presencia de uno o ms errores en el software objeto de la prueba. En realidad no se puede garantizar que no surjan fallas posteriores en el sistema.

8.3. Algunas personas argumentan que los desarrolladores no deben intervenir en las pruebas de su propio cdigo, sino que todas las pruebas deben ser responsabilidad de un equipo independiente. Exponga argumentos en favor y en contra de las pruebas efectuadas por de los mismos desarrolladores. R= EN CONTRA: Por qu? Porque las pruebas de software debe ser un proceso destructivo. Se disea para hacer que el comportamiento de un programa sea distinto del que intentaba su diseador o aplicador. Como es una caracterstica humana natural que un individuo tenga cierta afinidad con los objetos que ha construido, el programador responsable de la aplicacin del sistema no es la persona ms apropiada para probar un programa. Psicolgicamente, el programador no querr destruir su creacin, lo cual har que, de manera consciente o inconsciente, elija pruebas que fallan, por lo que no sern adecuadas para demostrar la presencia de errores en el sistema.

A FAVOR: Por qu? Porque si los que probaran el software fuese un equipo independiente haran todas las pruebas necesarias. Estas personas desconocen del cdigo por lo cual puede que ingresen datos errados o datos correctos, as de esta manera detectar algunos posibles errores que se pueden corregir, as como darle formato a cualquier salida de datos. 8.4. Se pide al lector poner a prueba un mtodo llamado "catWhiteSpace" en un objeto "Paragraph" que, dentro del prrafo, sustituye secuencias de caracteres blancos con un solo carcter blanco. Identifique las particiones de prueba para este ejemplo y derive un conjunto de pruebas para el mtodo "catWhiteSpace". R= Particiones de las pruebas son los siguientes: Las cadenas con 1 espacio en blanco entre sus caracteres Las cadenas con ms de 2 espacios en blanco entre sus caracteres. Ms de 1 espacio en blanco entre 2 cadenas Ejemplos de pruebas: El veloz murc ilago hind salt sobre el perro perezoso. (Las cadenas con 1 espacio en blanco entre sus caracteres) El veloz murci lago hind salt sobre el perro perezoso. (Las cadenas con ms de 2 espacios en blanco entre sus caracteres) El veloz murcilago hind salt sobre el perro perezoso. (Ms de 1 espacio en blanco entre 2 cadenas) 8.5. Qu es la prueba de regresin? Explique cmo el uso de pruebas automatizadas y un marco de pruebas como JUnit simplifican las pruebas de regresin. R=Las pruebas de regresin es el proceso de ejecucin de las pruebas de funcionalidad que ya se ha implementado una nueva funcionalidad que se ha desarrollado el sistema o se cambia. Pruebas de regresin es comprobar que los cambios del sistema no han introducido problemas en el cdigo realizado anteriormente. Las pruebas automatizadas y un marco de pruebas, tales como JUnit, simplifican radicalmente las pruebas de regresin como el conjunto completo de la prueba se puede ejecutar de forma automtica cada vez que se realiza un cambio. Las pruebas automatizadas incluyen sus propios controles que la prueba ha tenido xito o que de lo contrario los costos de la comprobacin del xito o el fracaso de las pruebas de regresin es bajo.

8.6. El MHC-PMS se construy al adaptar un sistema de informacin comercial. Cules considera usted que son las diferencias entre probar tal sistema y probar el software que se desarroll un lenguaje orientado a objetos como Java? R= Para dicho caso la diferencia que entre probar software y probar el sistema sera, que al probar el software estamos probando cada fragmento del cdigo en dicho lenguaje de programacin, cada clase que posee el software, cada funcin, cada segmento de nuestro cdigo para as efectuar la correccin de errores y encontrar algunos bugs que puedan alterar el funcionamiento de nuestro software. Al probar el sistema lo que estamos haciendo es probar la implementacin del sistema a un escenario, es decir como sera el funcionamiento final del software en conjunto con todos los subsistemas a los cuales lo estamos implementando para poder lograr el sistema que deseamos. Para el MHC-PMS debemos hacer pruebas del software cuando se Registra un Paciente, cuando se prescribe un medicamento, cuando se le otorga el tratamiento, pruebas de verificacin en la base de datos, para saber que hay buen empleo de la informacin. Y Para corroborar que el Sistema este completo se debe probar todo el sistema ya implementando el hardware, las redes y el mismo software en s. Compatibilidades etc. 8.7. Disee un escenario que pueda usar para ayudarse a elaborar pruebas para el sistema de estacin meteorolgica en campo abierto. R= Para ayudar a monitorizar el cambio climtico y mejorar la exactitud de las predicciones meteorolgicas en reas remotas, el gobierno de la Repblica de Panam decidi instalar varios cientos de estaciones meteorolgicas en reas de campo abierto. Las estaciones meteorolgicas recopilan datos de un conjunto de instrumentos que miden temperatura y presin, luz solar, lluvia, y rapidez y direccin del viento. Cada estacin meteorolgica incluye algunos instrumentos que miden parmetros climatolgicos como rapidez y direccin del viento, temperaturas del terreno y aire, presin baromtrica y lluvia durante un periodo de 24 horas. Cada uno de dichos instrumentos est controlado por un sistema de software que toma peridicamente lecturas de parmetros y gestiona los datos recolectados desde los instrumentos. El sistema de estacin meteorolgica opera mediante la recoleccin de observaciones meteorolgicas a intervalos frecuentes; por ejemplo, las temperaturas se miden cada minuto. Sin embargo, puesto que el ancho de banda del satlite es relativamente estrecho, la estacin meteorolgica realiza cierto procesamiento local y concentracin de los datos. Luego, transmite los datos concentrados cuando los solicita el sistema de adquisicin de datos. Pero si, por cualquier razn, es imposible realizar una conexin, entonces la estacin meteorolgica mantiene los datos localmente hasta que se reanude la comunicacin. Cada estacin meteorolgica es alimentada por bateras y debe estar completamente auto contenida: no hay fuentes de energa externas o cables de red disponibles. Todas las comunicaciones son a travs de un vinculo satelital de rapidez relativamente baja, y la estacin meteorolgica debe incluir algn mecanismo (solar o elico) para cargar sus bateras. Puesto que se

despliegan en reas abiertas, estn expuestas a severas condiciones ambientales y los animales llegan a daarlas. Por lo tanto, el software de la estacin no solo se encarga de la adquisicin de datos. Tambin debe: 1. Monitorizar los instrumentos, la energa y el hardware de comunicacin, y reportar las fallas al sistema de administracin. 2. Administrar la energa del sistema, garantizar que las bateras estn cargadas siempre que las condiciones ambientales lo permitan; as como desconectar los generadores ante condiciones meteorolgicas potencialmente adversas, como viento fuerte. 3. Permitir la reconfiguracin dinmica donde partes del software se sustituyan con nuevas versiones, y los instrumentos de respaldo se enciendan en el sistema en caso de falla de este, Puesto que las estaciones meteorolgicas deben estar auto contenidas y sin vigilancia, esto significa que el software instalado es complejo, aun cuando la funcionalidad de adquisicin de datos sea bastante simple. 8.8. Qu entiende por "pruebas de esfuerzo"? Sugiera cmo puede hacer una prueba de esfuerzo del MHC-PMS. R= Las pruebas de esfuerzo son las pruebas realizadas al software en cada uno de sus objetos y funcionalidades que este contenga para encontrar algn tipo de falla o problema para que este sea reparado y el software as a su vez tendr una mayor funcionalidad. Este tipo de pruebas de esfuerzo se realizan hasta que el sistema tenga pocas fallas. Para el sistema MHC-PMS se deberan realizar pruebas en el manejo de la informacin del paciente, ya que si falla el software al momento de diagnosticar y prescribir una receta a un paciente, puede ocasionar la muerte del paciente o alguna otra intoxicacin. Se debe manipular una buena informacin en lo que es la parte del inventario de medicamentos de la clnica u hospital, ya que no se puede prescribir medicamentos sin que se encuentre suficiente cantidad de medicamentos. Se debe probar el Tipo de Tratamiento y El doctor que se le asignar en su atencin (Ya Que Si uno va a atenderse con un Gineclogo, no se debe asignar un Cardilogo). Todas estas y muchas ms son pruebas que deben realizarse al MHC-PMS, Esforzarse para que el sistema tenga mnimas fallas y siempre est disponible, tambin se debe probar lo que es el multiusuario. 8.9. Cules son los beneficios de hacer participar a usuarios en las pruebas de versin en una etapa temprana del proceso de pruebas? Hay desventajas en la implicacin del usuario? R= Las pruebas de versin son el proceso de poner a prueba una versin particular de un software en un sistema, que se pretende usar fuera del equipo de desarrollo. Por lo general, las versiones podran ser para otros equipos que desarrollan sistemas relacionados. Para productores de software, la versin se debe realizar y enviar un informe al gerente del producto, quin despus la prepara para su venta.

Se puede mencionar que existen dos distinciones entre las pruebas de versin y las pruebas del sistema durante el proceso de desarrollo. Un equipo independiente que no intervino en el desarrollo del sistema debe ser el responsable de las pruebas de versin. Las Pruebas del sistema son por parte del equipo de desarrollo y deben enfocarse en el descubrimiento de bugs en los sistemas (Pruebas de defecto). El objetivo de las pruebas de versin es comprobar que el sistema cumpla con todos los requerimientos y sea suficientemente bueno para uno externo (Prueba de validacin). Existe una gran ventaja en la implicacin del usuario en una prueba de versin ya que el usuario es el que va a dictaminar si el sistema cumple los requerimientos que se queran, y es una etapa en la cual se puede comprobar si se puede aadir un requerimiento que haga falta (comprobacin), al tener la intervencin del usuario se puede concluir si la versin probada satisface o no las necesidades del usuario. 8.10. Un enfoque comn a las pruebas del sistema es probar el sistema hasta que se agote el presupuesto de pruebas y, luego, entregar el sistema a los clientes. Discuta la tica de enfoque para sistemas que se entregan a clientes externos. R= Un verdadero Ingeniero de Sistemas con una gran preparacin profesional, debe ser capaz de implementar un sistema, en el cual ya se le haya realizado la cantidad de pruebas necesarias. Y debe considerar que las pruebas deben realizarse hasta que el software contenga la menor cantidad de fallas, ya que al agotarse el presupuesto se termina el periodo de pruebas y el software puede seguir fallando y este traer un gran problema para el cliente que est invirtiendo en el sistema que se est implementando. Lo mejor que puede hacer el Ingeniero es que si el sistema contiene muchas fallas este no sea entregado a un cliente, ya que esto conlleva a que el cliente gaste el doble de su inversin, es mucho ms costoso encontrar y reparar luego de la construccin del software, as se puede practicar la tica profesional. Al igual entregando un software en el cual tanto el cliente se sienta satisfecho con la inversin realizada, y la automatizacin de su empresa, es un buen ejemplo de prctica de tica profesional.

Bibliografa

Libro: Ingeniera de Software, 9 edicin. Autor: Ian Sommerville. Editorial: PERSON educacin, 2011. . Libro: UML, y Patrones. Introduccin al anlisis y diseo orientado a objetos. Autor: Craig Larman Editoria:l Pearson. Libro: Ingeniera de Software. Teora y Prctica Autor: Shari Lawrence Editorial: Prentice Hall, 2002. Libro: Ingeniera de Software, 5 Edicin. Autor: Roger Pressman Editorial: McGraw-Hill, 2002. Libro: Ingeniera de Software Orientada a Objetos. Autor: Bernard Bruegge, Allen H. Dutoit. Editorial: Prentice Hall, 2002. Ttulo: Pruebas y Depuracin. Sitio Web: http://html.rincondelvago.com/ingenieria-de-software_4.html Ttulo: Tema 9. Pruebas del Software Sitio Web: http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema09.pdf Ttulo: Pruebas del Software. Sitio Web: http://es.wikipedia.org/wiki/Pruebas_de_software Ttulo: Pruebas de Software. Sitio Web: http://www.slideshare.net/aracelij/pruebas-de-software Ttulo: Los 5 Tipos de Pruebas del Software. Sitio Web: http://robertoyudice.com/general/los-5-tipos-de-prueba-del-software/