UNIVERSIDAD UNIVERSIDAD TECNOLÓGICA DE PANAMÁ FACULTAD DE INGENIERÍA DE SISTEMAS COMPUTACIONALES DEPARTAMENTO DEPARTAMENTO DE INGENIERÍA DE SOFTWARE INGENIERÍA INGENIERÍA DE SOFTWARE II PRUEBAS DE SOFTWARE CAPÍTULO 8 10 EJERCIOS ESTUDIANTE: GOOD LUIS LUIS NAYSI SAMANIEGO SAMANIEGO RAÚL PROFESORA: ANA GLORIA GLORIA CORDERO DE HERNÁNDEZ HERNÁNDEZ M.SC. GRUPOS: 1IL132 FECHA DE ENTREGA: ENTREGA: 13 DE OCTUBRE DE 2011 II SEMESTRE, 2011
Ejercicios Prácticos Prácticos – Capítulo 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, sobr sobre e todo todo las las prue prueba bass de def defecto ectos, s, algu alguna nass de ésta éstass son son las las que nos nos demostrarán que el programa cumple con sus requerimientos. A parte no se puede demostrar demostrar que el software software esté en su totalidad totalidad libre libre de defectos defectos o que se comporte como hayamos especificado en X circunstancia. Siempre es posible que una prueba que demos por alto descubra más problemas en el sistema. sistema. “Las “Las prueba pruebas s pueden pueden mostrar mostrar sólo sólo la prese presenci ncia a de errore errores, s, mas no su ausencia.”
8.2. Indique por qué las pruebas sólo 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 depuración es el proceso de localizar dónde se produjeron esos errores y correg corregir ir el código código incorre incorrect cto. o. Es muy import important ante e compre comprende nderr que la prueba prueba nunca nunca demuestra que un programa es correcto. Siempre es posible que existan errores aun después de la prueba más completa. La prueba de programas sólo puede demostrar la presencia de errores en un programa, no su ausencia, se considera prueba acertada aquella que establece la presencia de uno o más errores en el software objeto de la prueba. En realidad no se puede garantizar que no surjan fallas posteriores en el sistema.
8.3. Algu 8.3. Alguna nass pers person onas as argu argume ment ntan an que que los los desa desarr rrol olla lado dore ress no debe deben n intervenir en las pruebas de su propio código, sino que todas las pruebas debe deben n se serr res respons ponsab abil iliidad dad de un equ equipo ipo inde indepe pen ndie diente nte. Expo Expong ngaa argumentos en favor y en contra de las pruebas efectuadas por de los mismos desarrolladores. desarrolladores. R= EN CONTRA: ¿Por qué? Porque las pruebas de software debe ser un proceso destructivo. Se diseña para hacer que el comportamiento de un programa sea distinto del que intentaba su diseñador o aplicador. Como es una característica humana natural que un individuo tenga cierta afinidad con los objetos que ha construido, el programador responsable de la aplicación del sistema no es la pers person ona a más más apro apropi piad ada a para para prob probar ar un prog progra rama ma.. Psic Psicol ológ ógic icam amen ente te,, el progra programa mado dorr no querr querrá á “des “destr trui uir” r” su creac creació ión, n, lo cual cual hará hará que, que, de mane manera ra consciente o inconsciente, elija pruebas que fallan, por lo que no serán 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 harían todas las pruebas necesarias. Estas personas desconocen del código 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 método llamado "catWhiteSpace" en un objet objeto o "Paragr "Paragraph" aph" que, que, dentro dentro del párraf párrafo, o, sustit sustituy uye e se secue cuencia ncias s de caracteres blancos con un solo carácter blanco. Identifique las particiones de prueba para este ejemplo y derive un conjunto de pruebas para el método "catWhiteSpace". R= Particiones de las pruebas son los siguientes: siguientes: Las cadenas con 1 espacio en blanco entre sus caracteres Las cadenas con más de 2 espacios en blanco entre sus caracteres. Más de 1 espacio en blanco entre 2 cadenas •
• •
Ejemplos de pruebas: El veloz murc iélago 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 más de 2 espacios en blanco entre sus caracteres) El veloz murciélago hindú saltó sobre el perro perezoso. (Más de 1 espacio en blanco entre 2 cadenas)
8.5. ¿Qué es la prueba de regresión? Explique cómo el uso de pruebas automatizadas y un marco de pruebas como JUnit J Unit simplifican las pruebas de regresión. R=Las pruebas de regresión es el proceso de ejecución de las pruebas de funcionalidad que ya se ha implementado una nueva funcionalidad que se ha desarrollado el sistema o se cambia. Pruebas de regresión es comprobar que los camb cambio ioss del del sist sistem ema a no han han intr introd oduc ucid ido o probl problema emass en el códi código go reali realizad zado o anteriormente. Las pruebas automatizadas y un marco de pruebas, tales como JUnit JUnit,, simpl simplifific ican an radi radica calm lmen ente te las las prue prueba bass de regr regres esió ión n como como el conj conjunt unto o completo de la prueba se puede ejecutar de forma automática 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 comprobación del éxito o el fracaso de las pruebas de regresión es bajo.
8.6. El MH 8.6. MHCC-PM PMS S se cons constr truy uyó ó al adap adapta tarr un sist sistem emaa de info inform rmac ació ión n comercial. ¿Cuáles considera usted que son las diferencias entre probar tal sistema y probar el software que se desarrolló un lenguaje orientado a objetos como Java? diferencia que entre entre probar software software y probar el sistema sistema R= Para dicho caso la diferencia sería, que al probar el software estamos probando cada fragmento del código en dicho lenguaje de programación, cada clase que posee el software, software, cada función, cada segmento de nuestro código para así efectuar la corrección 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 implementación del sistema sistema a un escenario, escenario, es decir como sería el funcionamient funcionamiento o final del software 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 Paci Pacien ente te,, cuan cuando do se pres prescr crib ibe e un medi medica came ment nto, o, cuan cuando do se le otor otorga ga el tratamiento, pruebas de verificación en la base de datos, para saber que hay buen empleo de la informa información. ción. Y Para corroborar corroborar que el Sistema Sistema este completo completo se debe probar todo el sistema ya implementa implementando ndo el hardware, hardware, las redes y el mismo software en sí. Compatibilidades etc. 8.7. Diseñe un escenario que pueda usar para ayudarse a elaborar pruebas para el sistema de estación meteorológica en campo abierto. Par r a ay ayud uda ar a moni nito toririzar zar el el cam camb bio climát átiico y me j jo or ar la exacti exactitu tud d de las R= Pa pr edicc icciiones mete meteo oro roló lóg gicas en ár eas rem remot ota as, el go gobi bier er no de la República de Panamá deci ecidi dió ó in i nstalar var ios ci c ientos de est es tacio acione ness met meteo eoro rológ lógiicas en en ár eas eas de campo abierto. abierto. Las esta estaccio ione ness meteo eor r oló lóg gicas r ecop ecopilan datos de un conjunto conjunto de instr in str umen umenttos qu que e miden temper atur a y pr esi esión, lu luzz so sollar , llu luvia via,, y rapidez y dir di r ección ección del vient nto o. Cad Ca da est es tac aciión meteo meteor r ológ ógiica inc incluye algu lgun nos in insstr ume men ntos qu que miden parámetro arámetross clilimatoló matológ gicos como rapi rapidez y dir ecci ecció ón del del vien viento to,, tem temp perat eratu ura rass del terreno y air e, presión bar ométr ométr ica y lluvia dur ante ante un per iodo iodo de 24 horas hora s. Cada uno de di dichos insstr umento in mentoss está cont contr olad olado o por un por un sistema de sof tware que toma tom a periódicame periódicamen nte lectu lect uras de parám parámetros y gesti gestiona lo loss dato toss recolectados desde los los in instrumento trumentoss. El si sisste tem ma de es esttac aciión meteo eteor r ológic ógica a oper a medi media ante la re reco cole lecci cció ón de observa servacciones meteorológicas a int interv erva alos f r r ecuentes ecuentes; por ejemplo, las tem emp perat eratur ur as as se mid miden cada minu minuto. to. Si Sin n emb e mba ar go, go, pues estto qu que e el e l anch ncho o de banda dell saté de téllite es r elat atiivame vamen nte estrecho, la estación estación meteo eor r ológ ógiica re rea aliza cierto procesam rocesamiiento loca ocall y con conccentr aci ación de de los da dato toss. Luego ego,, tr ansmit mite e los dato toss concent ntrado radoss cuando los so sollici citta el sistem ema a de adquis isiició ción n de dato tos. s. Per o si, por cualqui lquie er razón razón,, es imposi imposibl ble e reali realizzar una con co nex exiión, entonces la es esttació ción n meteoro orollógica ma manti ntie ene los da dattos loc oca almente has astta que se s e r eanud eanude e la comu comunicac icaciión. Ca Cad da est es tación me m eteoro teorollóg ógiica es al a limen menttada por bate aterí rías as y debe es esttar compl completamente auto auto cont nte eni nida: da: no hay f uentes de energí rgía a extterna ex ernass o cabl ca bles es de r ed dis d isp ponib nibles les.. To Tod das las comu mun nicac icacion iones es son son a través de un vi vin nculo satel satelital de de rap rapidez r elativ iva amente ba j ja a, y la es esttac aciión me meteoro rollóg ógiica debe incclu in luirir al a lgún meca ecani nismo smo (so sollar r o o eólic e ólico) o) par a carga cargar r sus sus bate aterí rías as.. Pues Pu estto qu que e se
des espl pliega iegan n en ár á r eas eas abi abier tas, tas, est están ex expue puesstas a severas condicion condiciones am ambient nta ales y los anima animales llegan a dañarla dañarlass. Por lo Por lo ta tan nto to,, el software de la estación no so sollo se en encarga de la ad adquisición de datos os.. Tam Tamb bié ién n de deb be: 1. Mo Mon nito itor r izar izar lo loss instrumento trumentos, s, la energí energía y el hardwa hardwar r e de comun comunicación icación,, y repor tar r llas f allas al si sistema de admin admi nistr ación. ación. 2. Ad Adm min iniistr ar l ar la ener ener gía gía de dell sistem tema, a, gara ran ntiz tiza ar r q que las batería eríass esté estén n cargadas siempre qu que e las cond condiiciones ambi ambiental entale es lo permi permita tan; n; así co com mo desco escon necta ectar r los los gener gene r ador a dores es ant nte e condi dici cio ones meteo eor r ológicas ológicas potenc ncia iallme men nte adve ver r sas, como viento fuerte. fuerte. 3. Per mititir ir lla r econ econfig figur ur ación ación din dinámi mica ca dond nde e par tes del sof twa war r e se su sust stiituya yan n co con n nuev nu eva as version versiones es,, y los in inst strum rume ento ntoss de resp respald ldo o se enci encie end nda an en el sistema en caso de fall falla a de est este, Puesto que las est Puesto estac aciiones met mete eor ológic icas as deb debe en es esttar aut uto o con onttenidas y si sin n vigi gillancia, esto signif ica ica que el sof tware tware in inst sta alado es com comp ple j jo o, aun cuand ndo o la f uncio uncion nal alid ida ad de adqu adquis isiición de de dato datoss sea sea bas basttant nte e si simp mplle.
8.8. ¿Qué entiende por "pruebas de esfuerzo"? Sugiera cómo puede hacer una prueba de esfuerzo del MHC-PMS. realizadas al software software en cada uno R= Las pruebas de esfuerzo son las pruebas realizadas de sus objetos y funcionalidades que este contenga para encontrar algún tipo de falla o problema problema para que este sea reparado y el software software así a su vez tendrá una mayor funcionalidad. Este tipo de pruebas de esfuerzo se realizan hasta que el sistema sistema tenga tenga pocas fallas. fallas. Para el sistem sistema a MHC-PM MHC-PMS S se deberían deberían realiza realizar r pruebas en el manejo de la información 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 intoxicación. Se debe manipular una buena información en lo que es la parte del inventario de medicamentos de la clínica u hospita hospital,l, ya que no se puede prescrib prescribir ir medicame medicamento ntoss sin que se encuentre encuentre suficiente cantidad de medicamentos. Se debe probar el Tipo de Tratamiento y El doctor que se le asignará asignará en su atención atención (Ya Que Si uno va a atenderse atenderse con un Ginecólogo, Ginecólogo, no se debe asignar asignar un Cardiólogo). Cardiólogo). Todas estas estas y muchas más son pruebas que deben realizarse al MHC-PMS, Esforzarse para que el sistema tenga mínimas mínimas fallas fallas y siempre esté disponible disponible,, también también se debe probar lo que es el multiusuario. 8.9. ¿Cuáles son los beneficios de hacer participar a usuarios en las pruebas de versió rsión n en una etapa apa temp temprrana ana del del proc proceeso de prueb ruebas as? ? ¿Hay ¿Hay desventajas en la implicación del usuario? R= Las pruebas de versión son el proceso de poner a prueba una versión particular de un software en un sistema, que se pretende usar fuera del equipo de desarrol desarrollo. lo. Por lo general general,, las versio versiones nes podrían podrían ser para otros equipo equiposs que desarrollan desarrollan sistemas sistemas relacionados relacionados.. Para productores productores de software, software, la versión versión se debe realizar y enviar un informe al gerente del producto, quién después la prepara para su venta.
Se puede mencionar que existen dos distinciones entre las pruebas de versión y las pruebas del sistema durante el proceso de desarrollo. Un equipo equipo indep independ endien iente te que no interv intervino ino en el el desarrol desarrollo lo del sist sistema ema debe ser el responsable de las pruebas de versión. Las Pruebas del sistema son por parte del equipo de desarrollo y deben enfo enfoca carse rse en el desc descubr ubrim imie ient nto o de bugs bugs en los los sist sistema emass (Prue (Prueba bass de defecto). El objetivo de las pruebas de versión es comprobar que el sistema cumpla con todos los requerimientos y sea suficientemente bueno para uno externo (Prueba de validación). Existe una gran ventaja en la implicación del usuario en una prueba de versión ya que el usuario es el que va a dictaminar si el sistema cumple los requerimientos que se querían, y es una etapa en la cual se puede comprobar si se puede añadir un requeri requerimie miento nto que haga falta falta (compro (comprobac bación ión), ), al tener tener la interv intervenc ención ión del usuario se puede concluir si la versión probada satisface o no las necesidades del usuario.
8.10. Un enfoque común a las pruebas del sistema es probar el sistema hasta que se agote el presupuesto de pruebas y, luego, entregar el sistema a los clie cl ient ntes es.. Disc Discut utaa la étic éticaa de enfo enfoqu quee para para sist sistem emas as que que se entr entreg egan an a clientes externos. R= Un verdadero Ingeniero de Sistemas con una gran preparación profesional, debe ser capaz de implemen implementar tar un sistema, sistema, en el cual ya se le haya realizado realizado la cantida cantidad d de pruebas pruebas necesar necesarias. ias. Y debe considera considerarr que las pruebas 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 sistema que se está impleme implementando ntando.. Lo mejor mejor que puede hacer el Ingeniero 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 inversión, es mucho más costoso encontrar y reparar luego de la construcción 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 inversión realizada, y la automatización de su empresa, es un buen ejemplo de práctica de ética profesional.
Bibliografía
Libro: Ingeniería de Software, 9° edición. Autor: Ian Sommerville. Editorial: PERSON educación, 2011. . Libro: UML, y Patrones. Introducción al análisis y diseño orientado a objetos. Autor: Craig Larman Editoria:l Pearson. Libro: Ingeniería de Software. Teoría y Práctica Autor: Shari Lawrence Editorial: Prentice Hall, 2002. Libro: Ingeniería de Software, 5° Edición. Autor: Roger Pressman Editorial: McGraw-Hill, 2002. Libro: Ingeniería de Software Orientada a Objetos. Autor: Bernard Bruegge, Allen H. Dutoit. Editorial: Prentice Hall, 2002. Título: Pruebas y Depuración. Sitio Web: http://html.rincondelvago.com/ingenieria-de-software_4.html Título: Tema 9. Pruebas del Software Sitio Web: http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Te http://alarcos.inf-cr.uclm.es/doc/ISOFTWAREI/Tema09.pdf ma09.pdf Título: Pruebas del Software. Sitio Web: http://es.wikipedia.org/wiki/Pruebas_de_software Título: Pruebas de Software. Sitio Web: http://www.slideshare.net/aracelij/pruebas-de-software Título: Los 5 Tipos de Pruebas del Software. Sitio Web: http://robertoyudice.com/general/los-5-tipos-de-prueba-del-software/
