Unidad 2.3 Prueba De Programas
Upcoming SlideShare
Loading in...5
×
 

Unidad 2.3 Prueba De Programas

on

  • 4,147 views

 

Statistics

Views

Total Views
4,147
Views on SlideShare
4,042
Embed Views
105

Actions

Likes
0
Downloads
131
Comments
0

2 Embeds 105

http://testingbaires.com 104
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Unidad 2.3 Prueba De Programas Unidad 2.3 Prueba De Programas Presentation Transcript

  • Ingeniería de Software Unidad II Prueba de los Programas 14 de abr de 2011 Sergio Sánchez Rios Sergio Sánchez Rios. Ingeniero en Informática – Licenciado en Informática
  • Introducción
    • Una vez codificados los programas es el momento de probarlos.
    • Existen muchos tipos de pruebas: prueba unitaria, prueba de integración, prueba de función, prueba de desempeño, prueba de aceptación y prueba de instalación.
    • Es importante considerar, que la etapa de prueba no es la primera instancia en que se localizan defectos; también las revisiones de requerimientos y diseño contribuyen a descubrir los problemas en instancias tempranas del desarrollo.
    • La etapa de prueba se centra en la búsqueda de defectos.
    14 de abr de 2011 Sergio Sánchez Rios
  • Defectos y Fallas del software
    • ¿Qué significa decir que el software a fallado?
    • Por lo general se interpreta que el software no hace lo que especifican los requerimientos. La falla puede ser el resultado de alguna de varias razones:
      • La especificación puede ser errónea o puede haberse omitido algún requerimiento.
      • La especificación puede contener un requerimiento que es imposible de implementar con el software y el hardware preescrito.
      • El diseño del sistema puede contener un defecto.
      • El diseño del programa puede contener un defecto.
      • El código del programa puede estar errado.
    14 de abr de 2011 Sergio Sánchez Rios Una falla es el resultado de uno o más defectos en algunos aspectos del sistema.
  • Defectos y Fallas del software
    • Muchos programadores consideran que la prueba es una comprobación de que sus programas operan correctamente.
    • La idea de demostración de exactitud es realmente lo inverso de lo que entraña la prueba.
    • Se prueba un programa para demostrar la existencia de un defecto. La prueba es destructiva: dado que la meta es descubrir defectos.
      • Identificación de defectos : es el proceso de determinar cuál o cuales son los defectos que originan las fallas.
      • Corrección de defectos o remoción: es el proceso de efectuar cambios al sistema de manera que se eliminen los defectos.
    14 de abr de 2011 Sergio Sánchez Rios
  • Defectos y Fallas del software Tipos de Defectos
    • Una de las cosas importantes al realizar las pruebas, es saber que clase de defectos se están buscando.
    • Defectos Algorítmicos
    • Se produce cuando el algoritmo o la lógica de un componente no producen la salida apropiada para una entrada dada, debido a que algo esta mal en los pasos del procesamiento.
    • Los tipos de defectos algorítmicos incluyen: bifurcar antes y después de tiempo, probar una condición errónea, olvidar inicializar una variable o fijar las constantes de un bucle, olvidar la prueba para una condición particular (división por cero), comparar variables de tipos de datos inapropiados, etc..
    14 de abr de 2011 Sergio Sánchez Rios
  • Defectos y Fallas del software Tipos de Defectos
    • Defectos de Sintaxis
    • Se realiza mientras se buscan defectos algorítmicos. En este caso, se desea asegurar que se han utilizado apropiadamente las estructuras del lenguaje de programación.
    • Defectos de computación y de precisión
    • Ocurre cuando la implementación de una fórmula es errónea o no calcula el resultado con el grado requerido de exactitud. Ej.: Mezcla de flotantes y enteros resultado inesperado.
    • Defectos de Documentación
    • Es cuando la documentación no corresponde con lo que el programa realmente hace. Se tiende a confiar en la documentación al pasar de una etapa a otra y al modificar.
    14 de abr de 2011 Sergio Sánchez Rios
  • Defectos y Fallas del software Tipos de Defectos
    • Defectos por estrés o sobrecarga
    • Se producen cuando las estructuras (longitud de colas, tamaño de almacenamiento temporarios (buffers), a la dimensión de tablas y así sucesivamente) se llenan hasta sobrepasar su capacidad especifica.
    • Defectos de capacidad o de limites
    • Ocurre cuando el desempeño del sistema se vuelve inaceptable a medida que la actividad del sistema alcanza su limite especificado. Ej.: Sistema diseñado con 32 dispositivos, se debe probar si funciona con los 32 dispositivos trabajando.
    • Defecto de rendimiento o desempeño
    • Ocurre cuando el sistema no opera a la velocidad preescrita por los requerimientos.
    14 de abr de 2011 Sergio Sánchez Rios
  • Defectos y Fallas del software Tipos de Defectos
    • Defectos de sincronización o de coordinación
    • Al desarrollar sistemas de tiempo real, una consideración critica es la coordinación de los varios procesos que se ejecutan simultáneamente o una secuencia rigurosa definida. El defecto se produce cuando el código que coordina dichos eventos es inadecuado.
    • Defectos de recuperación
    • Pueden ocurrir cuando se encuentra una falla y el sistema no se comporta como los diseñadores desean que lo haga, o como el lo quiere el cliente.
    • Defecto de Hardware y Software de sistemas.
    • Cuando el hardware suministrado y el software de sistemas no trabajan realmente de acuerdo con las condiciones operativas y procedimientos documentados.
    14 de abr de 2011 Sergio Sánchez Rios
  • Defectos y Fallas del software Tipos de Defectos
    • Defectos de estándares y procedimientos
    • El código será revisado para ver si se han seguido los estándares y procedimientos. Estos no siempre afectan la ejecución de los programas. Al no usar los estándares o procedimientos requeridos un programador puede hacer que para otros resulte muy difícil comprender la lógica del código.
    14 de abr de 2011 Sergio Sánchez Rios
  • Aspectos de la Prueba
    • Son muchos los tipos de prueba que se hacen antes de poder entregarle el sistema al cliente con la seguridad de que operara correctamente.
    14 de abr de 2011 Sergio Sánchez Rios Cada componente del programa se verifica en si mismo, aislado de los demás componentes del sistema. La prueba funcional, evalúa el sistema para determinar si las funciones descritas por la especificación son realmente ejecutadas por el sistema integrado. La prueba de integración, verifica que los componentes del sistema trabajan juntos conforme a lo descrito en la especificación del diseño del programa. Se realiza una prueba de rendimiento con el resto de requerimientos de software y hardware. Cuando la prueba se lleva acabo exitosamente, se produce un sistema valido. La prueba de aceptación se realiza en conjunto con el cliente; ya que el sistema se comprueba contra la especificación de requerimientos. La prueba de instalación se realiza para garantizar que todo funciona como corresponde.
  • Aspectos de la Prueba ¿Quién realiza las pruebas?
    • Muchas veces se manifiestan dificultades para separar los sentimientos personales del proceso de prueba. Por lo tanto, a menudo se utiliza un equipo de prueba independiente.
    • Justificación de un equipo independiente de prueba:
      • Es claro que nadie entrega su código para la prueba sino piensa que el código a sido realizado de acuerdo con la especificación, pero se puede estar demasiado apegado al código como para ser realmente objetivos y reconocer algunos de los defectos más sutiles.
      • Las pruebas pueden llevarse concurrentemente con la codificación; el equipo de prueba verifica los componentes a medida que son completados y comienza a consolidarlos mientras el plantel de programación continua codificando los demás.
    14 de abr de 2011 Sergio Sánchez Rios
  • Aspectos de la Prueba La visión de los objetos de prueba
    • Al probar un componente, un grupo de componentes, un subsistema o un sistema, la propia visión del objeto de prueba puede afectar la forma que se lleva acabo la prueba.
    • Si el objeto de prueba se ve desde afuera, como una “caja negra” o “caja cerrada” , cuyo contenido se desconoce, las pruebas consisten en alimentar la caja negra con entradas y anotar cuales son las salidas que se producen.
    • En este caso la meta de la prueba es asegurarse que se ha ingresado toda clase de entradas y que la salida observada en cada caso corresponde a una salida esperada.
    • La ventaja de este tipo de prueba, es que esta libre de las restricciones impuestas por la estructura interna o lógica.
    14 de abr de 2011 Sergio Sánchez Rios
  • Aspectos de la Prueba La visión de los objetos de prueba
    • La desventaja de utilizar la prueba de caja negra en un componente, es que no se pueden seleccionar los casos de prueba más significativos porque no se tiene un conocimiento acabado del procesamiento.
    • Para superar este problema el objeto de prueba puede verse como una “caja abierta”, “caja de cristal”, “caja blanca” o “caja transparente” , luego; se puede utilizar la estructura interna del objeto de prueba, para probar las diferentes maneras.
    • Por ejemplo se pueden ejecutar casos de prueba que ejecuten todas las instrucciones y caminos de control que existen dentro del componente, para asegurase que el objeto de prueba está bien.
    14 de abr de 2011 Sergio Sánchez Rios
  • Aspectos de la Prueba La visión de los objetos de prueba
    • Ejemplo:
    14 de abr de 2011 Sergio Sánchez Rios Si n y m valen cada uno 100.000, un caso de prueba debe iterar mil millones de veces para ejecutar todos los caminos lógicos. Para acotar estos casos de prueba según la composición interna, se pueden asignar valores I que sean menor que n, igual que n, y mayor que n. De igual forma se pueden asignar valores de J con relación a m.
  • Aspectos de la Prueba La visión de los objetos de prueba
    • Cuando se decide como probar, no es necesario seleccionar exclusivamente pruebas de caja abierta y cerrada. Se puede considerar que las pruebas de caja cerrada es uno de los extremos y la prueba de caja abierta el otro. Este proceso se llama caja estructurada (desde caja cerrada a abierta).
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba Unitaria
    • ¿Cómo comenzar cuando la meta es encontrar defectos?.
    • El proceso es similar al que se utiliza, cuando se prueba un programa asignado como tarea en la universidad:
    • Se examina el código, leyendo minuciosamente, tratando de localizar defectos en los algoritmos, los datos y la sintaxis.
    • Comparar el código con las especificaciones y con el diseño hasta tener la certeza de considerar todos los casos relevantes.
    • Finalmente se desarrollan los casos de prueba para demostrar que las entradas se convierten realmente en las salidas esperadas.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba Unitaria El examen del código
    • El proceso de revisión del código es similar al de la revisión de requerimientos y diseño. Se conforma un equipo, integrado por el mismo programador y tres o cuatro expertos técnicos.
    • Este equipo se encarga de estudiar el programa de manera organizada para localizar defectos. En estas pruebas no se incluyen clientes (examen de código).
    • Existen dos tipos de revisiones de códigos: las recorridas y las inspecciones.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba Unitaria El examen del código – Recorridos de código
    • Se presenta el código y la documentación correspondiente al equipo de revisión y el equipo comenta sobre su exactitud.
    • Durante la recorrida es el programador quien lidera y controla la discusión.
    • La atmósfera es informal y el foco de atención está en el código no en el programador.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba Unitaria El examen del código – Inspección de código
    • Este método fue presentado por Fagan (1976) en IBM. Es similar a una recorrida pero más formal. El equipo revisa el código y la documentación contra una lista de puntos de interés preparados.
    • La inspección involucra varios pasos:
    • El equipo debe reunirse para hacer una revisión general del código y hacer una descripción de las metas de la inspección.
    • Los miembros del equipo se preparan individualmente para una segunda reunión de grupo. Cada inspector estudia el código y sus documentos relacionados y resalta los defectos encontrados.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba Unitaria El examen del código – Inspección de código
    • Finalmente, los miembros del equipo informan lo que han encontrado y registran los defectos que se descubren durante el proceso de discusión de los defectos descubiertos por los individuos.
    • Los miembros del equipo de inspección se seleccionan sobre la base de las metas de la inspección. Ej.: Si se quieren inspeccionar las interfaces, alguno de los miembros del equipo a lo menos debe ser diseñador de interfaces.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba Unitaria Éxito de las revisiones de código
    • Puede sentirse incomodidad al tener a un grupo revisando el código propio.
    • Sin embargo, las revisiones han demostrado ser extraordinariamente exitosas en la detección de defectos, y por lo general están incluidas en la lista de prácticas obligatorias o de las mejores prácticas de una organización.
    • Por esta razón Gild (1988) y Gild y Graham (1993) sugieren inspeccionar no sólo el código, sino los artefactos tempranos del desarrollo tales como la especificación de requerimientos y el diseño.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba Unitaria Éxito de las revisiones de código
    • Jones (1991), realiza una investigación que denota la importancia de la inspección como una técnica de localización de defectos.
    • Defectos encontrados durante las actividades de descubrimiento
    14 de abr de 2011 Sergio Sánchez Rios Actividad de Descubrimiento Defectos encontrados por cada mil líneas de código Revisión de los requerimientos 2,5 Revisión del diseño 5,0 Inspección del código 10,0 Prueba de integración 3,0 Prueba de aceptación 2,0
  • Prueba Unitaria Casos de Prueba
    • Un buen test case es aquel que tiene una alta probabilidad de encontrar un defecto no descubierto, no aquel en que el programa funciona correctamente.
    • Un buen test case no es redundante, ni muy simple, ni muy complejo .... idealmente, el mejor de su clase.
    • Un exitoso test case es aquel que descubre un defecto no descubierto.
    • El diseño de test cases es muy difícil.
    • El Testing no puede mostrar la ausencia de defectos, sólo puede mostrar que los defectos están presentes.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba Unitaria Casos de Prueba
    • Existen dos estrategias para definir los casos de prueba:
    • Caja Negra – Black Box Testing
    • Métodos más Usados
      • Particionamiento de Equivalencias.
      • Análisis de Valores Fronteras.
      • Adivinanza de Defectos.
      • Métodos menos Usados
      • Diagrama causa - efecto .
      • Pruebas Sintácticas.
      • Pruebas de Transición de Estados.
      • Matriz de Grafos
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba Unitaria Casos de Prueba
    • Existen dos estrategias para definir los casos de prueba:
    • Caja Blanca – White Box Testing
    • Métodos más Usados
      • Pruebas de Cobertura (Instrucción, Decisión, Condición, Decisión/Condición, Múltiples Condiciones, De Caminos) .
      • Métodos menos Usados
      • Pruebas de caminos básicos.
      • Pruebas de Estructuras de Control.
      • Pruebas de Condición.
      • Pruebas de Flujo de Datos.
      • Pruebas de Loop.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba de Integración
    • Cuando se llega a un convencimiento de los componentes individuales están trabajando correctamente y se satisfacen los objetivos, se los combina en un sistema activo.
    • Esta integración se planea y coordina para que al producirse una falla, se pueda tener alguna idea de lo que le ha dado origen.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba de Integración Integración Ascendente (bottom – up)
    • Este enfoque permite realizar pruebas desde los componentes elementales a los más generales.
    • Cuando se usa este método, se prueba primero en forma individual cada componente al nivel más bajo de la jerarquía del sistema. Luego los próximos componentes que se prueban son lo que llaman a los ya probados.
    • Este método es útil cuando muchos de los componentes de bajo nivel son rutinas utilitarias de uso general que son invocados a menudo por otros componentes.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba de Integración Integración Ascendente (bottom – up)
    • Considerando está jerarquía se comienza probando los módulos E, F, G. Como no existe ningún programa preparado para llamar a estos programas del más bajo nivel, se escribe un código especial para llamar a la integración.
    • Este código se llama, controlador de componentes (Driver) , es una rutina que llama a un componente particular y le pasa un caso de prueba.
    14 de abr de 2011 Sergio Sánchez Rios A B C D E F G
  • Prueba de Integración Integración Ascendente (bottom – up)
    • Considerando la jerarquía planteada anteriormente estos son los pasos de la prueba.
    14 de abr de 2011 Sergio Sánchez Rios Probar E Probar F Probar G Driver E Driver F Driver G Casos de prueba Probar E, F, B Probar C Probar G, D Se prueban nuevamente los componentes E, F, B, C, G, D Probar A, B, C, D, E, F y G Se prueban todos los componentes juntos. Si los componentes probados no están OK no se pasa al otro nivel.
  • Prueba de Integración Integración Ascendente (bottom – up)
    • En un enfoque funcional, la queja radica en que al ser los módulos superiores los más importantes son los últimos en ser probados.
    • Por otra parte, este enfoque es a menudo el más razonable para los programas orientados a objeto. Los objetos se combinan de uno por vez con objetos o colecciones de objetos que se han probado previamente.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba de Integración Integración Descendente (Top – down)
    • Es lo contrario del bottom – up.
    • El componente principal se prueba aisladamente, después todos los componentes llamados por el componente se combinan y se prueban como una unidad mayor. Este enfoque se vuelve a aplicar hasta que todos los componentes estén incorporados.
    • Un componente que se esta probando puede llamar a otro todavía no probado, de modo que se escribe un programa de propósito especial que simule la actividad del componente omitido, denominado “talón” (stuk) .
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba de Integración Integración Descendente (Top – down)
    • Ejemplo basado en la jerarquía anterior:
    14 de abr de 2011 Sergio Sánchez Rios Probar A Probar A, B, C, D Probar B, C, D, E F, G Talones para B, C, D Talones para E, F, G En la prueba descendente no se necesitan programas controladores. Por otro lado la escritura de los talones puede ser difícil, porque estos deben permitir probar todas las posibles condiciones. Otra problemática es que si el diseño se cambia los talones también.
  • Prueba de Integración Integración Descendente (Top – down)
    • Una desventaja de esta técnica es la posibilidad de requerir números muy grandes de talones. Está situación se produce cuando el nivel más bajo tiene muchas rutinas.
    • Una manera de evitar este problema es alterar ligeramente la estrategia. En lugar de incorporar un nivel completo por vez, un enfoque descendente modificado prueba los componentes de cada nivel individualmente antes de llevar a cabo la fusión.
    14 de abr de 2011 Sergio Sánchez Rios Probar A Probar B Probar C Probar D Probar A, B, C, D Probar E Probar F Probar G Probar A, B, C, D, E, F, G
  • Prueba de Integración Integración Descendente (Top – down)
    • La prueba por separado de los componentes de cada nivel trae aparejado otra dificultad, se necesitan talones y controladores para cada componente, lo que lleva a que aunque aumenten considerablemente las tareas de codificación.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba de Integración Integración Big - Bang
    • Cuando todos los componentes se prueban por separado, existe la tentación de mezclarlos juntos como un sistema final y ver si funciona la primera vez.
    • Myers (1979) ha llamado prueba big – bang ha este particular enfoque de prueba.
    • Muchos programadores usan este enfoque para sistemas pequeños, pero no es práctico para los grandes.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba de Integración Integración Big - Bang 14 de abr de 2011 Sergio Sánchez Rios Probar A Probar B Probar C Probar D Probar E Probar F Probar G Probar A, B, C, D E, F, G Desventajas, exige talones y controladores que prueben los componentes independientes. Otra es que todos los componentes se fusionan (combinan a la vez), por esto es difícil encontrar la causa de fallas.
  • Prueba de Integración Integración Intercalada
    • Meyer (1979) combina las estrategias bottom – up y top –down para formar un enfoque de prueba intercalada.
    • El sistema de se como tres capas, al igual que un sandwich: en el medio la capa objetivo, los niveles por encima del objetivo y los niveles por debajo del objetivo.
    • En la capa superior se utiliza top – down y en la capa inferior bottom – up. La prueba converge a la capa objetivo, elegida en base a las características del sistema y a la estructura de la jerarquía del componente.
    • Este enfoque permite utilizar el enfoque bottom - up para verificar lo correcto de los utilitarios al principio de la prueba. Por lo tanto no se necesita escribir talones para los utilitarios porque están disponibles.
    14 de abr de 2011 Sergio Sánchez Rios
  • Prueba de Integración Integración Intercalada
    • Basados en el ejemplo anterior, el nivel objetivo es el nivel medio, compuesto por los componentes B, C y D.
    14 de abr de 2011 Sergio Sánchez Rios Probar E Probar F Probar G Probar E, F, B Probar G, D Probar A, B, C, D, E, F y G Probar C Probar A
  • Prueba de Integración Integración Intercalada
    • Este enfoque mezcla las ventajas de los dos métodos. Sin embargo, no permite probar los componentes antes de la integración.
    • La prueba intercalada modificada, permite probar los componentes antes de unirlos con otros.
    14 de abr de 2011 Sergio Sánchez Rios Probar E Probar F Probar G Probar E, F, B Probar G, D Probar A, B, C, D, E, F y G Probar C Probar A Probar D Probar B
  • Bibliografía 14 de abr de 2011 Sergio Sánchez Rios
    • Guía del Tópico:
    • Software Engineering 6a. ed.– Ian Sommerville – Pearson Education – 2000.
    • Ingeniería de Software Teoría y Práctica – Shari Lawrence Pfleeger – Pearson Education – 2002.
    • Solo referencial:
    • Ingeniería de Software: Un enfoque práctico - Roger S. Pressman - Mc Graw Hill – 2002.