• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Aguirre Jimenez
 

Aguirre Jimenez

on

  • 7,190 views

 

Statistics

Views

Total Views
7,190
Views on SlideShare
4,357
Embed Views
2,833

Actions

Likes
2
Downloads
327
Comments
1

9 Embeds 2,833

http://farova2.blogspot.mx 1818
http://farova2.blogspot.com 975
http://farova2.blogspot.com.es 18
http://farova2.blogspot.com.ar 11
http://www.slideshare.net 4
http://webcache.googleusercontent.com 4
http://74.125.113.132 1
http://farova2.blogspot.in 1
http://farova2.blogspot.de 1
More...

Accessibility

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

11 of 1 previous next

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

    Aguirre Jimenez Aguirre Jimenez Presentation Transcript

    • MODELO DE PRUEBAS DE SOFTWARE DARWIN JIMENEZ CARLOS EDUARDO AGUIRRE INGENIERIA DE SISTEMAS
    • CONTENIDO
      • Definición de conceptos
      • Fundamentos de las pruebas de software
      • Objetivos de la prueba
      • Principios de la prueba
      • Facilidad de la prueba
      • Tipos de Pruebas
      • Proceso de Pruebas
    • CONTENIDO
      • Enfoques de pruebas
      • Prueba de la caja blanca
      • Prueba del camino básico
      • Prueba de la estructura de control
      • Prueba de la caja negra
    • 1. DEFINICIONES DE CONCEPTOS
      • 1. Falla (failure): Ocurre cuando un programa no se comporta de manera adecuada .
      • 2. Falta (fault): Tiene lugar en el código del programa. La existencia de una falta en el programa puede generar una falla en el sistema.
    • 1. Definiciones de Conceptos
      • 3. Error: Es una acción humana que provoca que un software contenga una falta. Un error puede significar la existencia de una falta en el programa, lo cual hace que el sistema falle.
    • 1. Definiciones de Conceptos
      • No se puede garantizar ni probar
      • que un sistema jamás falle, si no
      • que sólo se puede demostrar que
      • contiene faltas. No encontrar
      • faltas no significa que la prueba
      • haya sido exitosa. Solo lo es si se
      • han encontrado faltas.
    • 2. Fundamentos de las pruebas de Software
      • El ingeniero intenta construir el software partiendo de un concepto abstracto y llegando a una implementación tangible.
      • El ingeniero crea una serie de casos de prueba que intentan “demoler “ el software construido.
    • 3. Objetivos de las pruebas
      • La prueba es un proceso de ejecución de un programa con la intención de descubrir un error.
      • Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.
      • Una prueba tiene éxito si descubre un error no detectado hasta entonces.
    • 4. Principios de la Prueba
      • A todas las pruebas se les debería poder hacer un seguimiento has los requisitos del cliente.
      • Las pruebas debería planificarse mucho antes de su inicio.
      • El principio de Pareto es aplicable a la prueba del Software: el 80% de todos los errores descubiertos durante las pruebas surgen al hacer un seguimiento de sólo el 20% de todos los módulos del programa.
    • 4. Principios de la Prueba
      • Las pruebas deberían empezar por lo pequeño y progresar hacia lo grande.
      • No son posible las pruebas exhaustivas.
      • Para ser más efectivas, las pruebas deberían ser conducidas por un equipo independiente.
    • 5. Facilidad de Prueba
      • Es simplemente lo fácil que se puede probar un programa de computadora. Como la prueba es tan profundamente difícil, merece la pena saber que puede hacer para hacerlo más sencillo.
      • Debe existir una lista de comprobación
      • que proporcione un conjunto de
      • características que llevan a un
      • software fácil de probar.
    • 5. Facilidad de Prueba
      • Principios:
      • Operatividad: Cuanto mejor funcione más eficientemente se pude probar.
      • Observabilidad: Lo que ves es lo que pruebas.
      • Controlabilidad: Cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.
    • 5. Facilidad de Prueba
      • Principios:
      • Capacidad de Descomposición: Controlando el ámbito de las pruebas, podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión.
      • Simplicidad: Cuanto menos haya que probar, más rápidamente podremos probarlo.
    • 5. Facilidad de Prueba
      • Principios:
      • Estabilidad: Cuanto menos cambios, menos interrupciones a las pruebas.
      • Facilidad de comprensión: Cuanta más información tengamos, más inteligentes serán las pruebas.
    • 6. Tipos de Prueba
      • Pruebas de Verificación: Se revisa si el resultado corresponde a la especificación del sistema, es decir, si se está construyendo el sistema de manera correcta.
      • Pruebas de Validación: Se revisa si el resultado es realmente lo que el cliente quería.
    • 6.1 Técnicas de Pruebas
      • Pruebas de Regresión: Tiene como propósito verificar el sistema luego, de haberle introducido cambios, por ejemplo después de corregir una falta, de manera que se mantenga la funcionalidad especificada.
      • Pruebas de Operación: Su objetivo es verificar el sistema en operación por un largo período bajo condiciones normales de uso.
    • 6.1 Técnicas de Pruebas
      • Pruebas de Escala Completa: Trata de verificar el sistema en su carga máxima mediante de los parámetros a su valor límite y la interconexión del sistema con un máximo de equipos y usuarios simultáneos.
      • Pruebas de Rendimiento: Tiene como propósito medir la capacidad de procesamiento del sistema bajo diferentes cargas, incluyendo espacio de almacenamiento y utilización de la unidad de procesamiento.
    • 6.1 Técnicas de Pruebas
      • Pruebas de Sobrecarga : Pretende observar como se comparta el sistema cuando se le aplica una sobrecarga, más allá de las pruebas de escala completa y rendimiento.
      • Pruebas negativa: Tiene como propósito medir el estrés del sistema en situaciones inesperadas, como casos de uso que normalmente no serían utilizados de manera simultánea.
    • 6.1 Técnicas de Pruebas
      • Pruebas basada en requisitos o prueba de casos de uso : Intenta llevar a cabo pruebas basadas directamente en la especificación de requisitos.
      • Pruebas ergonómicas: Tienen como propósito probar los aspectos ergonómicos del sistema, en otras palabras, las interfaces hombre-máquina en el caso de que éstas existan. Ejemplo: Si los menús son lógicos y legibles, si los mensajes del sistema son visibles, si se puede entender los mensajes de falla, etc.
    • 6.1 Técnicas de Pruebas
      • Pruebas de documentación de usuario : Tiene como propósito probar la documentación de usuario, incluyendo el manual de éste y la documentación de mantenimiento y servicio.
      • Pruebas de aceptación o de validación: Pretende lograr una revisión final por parte de la organización que solicitó el sistema, lo cual, a menudo, significa validación del sistema. Llamado Prueba Alfa o Prueba Beta.
    • 6.1 Técnicas de Pruebas
      • Pruebas de documentación de usuario : Tiene como propósito probar la documentación de usuario, incluyendo el manual de éste y la documentación de mantenimiento y servicio.
      • Pruebas de aceptación o de validación: Pretende lograr una revisión final por parte de la organización que solicitó el sistema, lo cual, a menudo, significa validación del sistema. Llamado Prueba Alfa o Prueba Beta.
    • 6.1 Técnicas de Pruebas
      • PRUEBA DE LA ESTRUCTURA DE
      • CONTROL
      • Las pruebas son de gran importancia en la garantía de la calidad del software.
      • Estas variantes amplían la cobertura de la prueba y mejoran la calidad de la prueba de caja blanca.
        • Prueba de Condición
        • Prueba de Flujo de Datos
        • Prueba de Bucles
    • Prueba de condición
      • Método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en el módulo de un programa.
      • Esta prueba asegura en que cada condición del programa no contenga errores.
      • Una condición simple es una variable lógica o una expresión relacional.
      • La expresión relacional adquiere la siguiente forma: E 1 <operador relacional>E 2 ; donde E 1 y E 2 son expresiones aritméticas y <operador relacional> puede ser “<, <=, =, >, >=, ≠”
      • Una condición compuesta está formada por dos o más condiciones simples, operadores lógicos o paréntesis. Los operadores lógicos permitidos en una condición compuesta incluye OR(|), AND(&), NOT.
      • Una condición sin expresiones relacionadas se le denomina expresión lógica.
      • Si una condición es incorrecta, entonces es incorrecto al menos un componente de la condición. Los errores de una condición pueden ser:
        • Error en operador lógico
        • Error en variable lógica
        • Error en paréntesis lógico
        • Error en operador relacional
        • Error en expresión aritmética
      • Se han propuesto series de estrategias de prueba de condiciones:
        • Prueba de ramificaciones : Para una condición compuesta C, es necesario ejecutar al menos una vez las ramas verdadera y falsa de C y cada condición simple de C.
        • Prueba del dominio : Requiere la realización de 3 o 4 pruebas para una expresión relacional.
        • E 1 <operador relacional> E 2 se requieren tres pruebas para comprobar que el valor de E 1 es mayor, igual o menor que el valor de E 2. Por ejemplo si el operador relacional es incorrecto y E 1 y E 2 son correctos, entonces estas tres pruebas garantizan la detección de un error del operador relacional.
    • Prueba de flujo de datos
      • Selecciona caminos de prueba de un programa de acuerdo con la ubicación de las definiciones y los usos de las variables del programa.
      • Las estrategias de prueba de flujo de datos son útiles para seleccionar caminos de prueba de un programa que contenga sentencias if o bucles anidados.
      • Necesitamos conocer la estructura de cada condición o bloque (seleccionando un camino del programa, determinamos si el camino es factible para el programa)
    • Prueba de bucles
      • Técnica de prueba de caja blanca que se centra en la validez de las construcciones de bucles.
      • Se pueden definir 4 clases diferentes de bucles:
        • Simples,
        • Concatenados,
        • Anidados,
        • No estructurados
    • Bucles Bucles simples Bucles anidados Bucles concatenados Bucles no estructurados
      • Bucles simples:
      • Se les debe aplicar el siguiente conjunto de pruebas, donde n es el número máximo de pasos permitidos por el bucle
      • 1. Pasar por alto totalmente el bucle
      • 2. Pasar una sola vez por el bucle
      • 3. Pasar dos veces por el bucle
      • 4. Hacer m pasos por el bucle con m<n
      • 5. Hacer n-1 y n+1 pasos por el bucle
      • Bucles anidados:
      • Si se extendiera el enfoque de los bucles simples a los bucles anidados, el número de posibles pruebas aumentaría geomé-tricamente a medida que aumenta el nivel de anidamiento. Esto llevaría a un número imprescindible de pruebas.
      • Se sugiere un enfoque que ayuda a reducir el número de pruebas
        • 1. Comenzar por el bucle más interior
        • 2. Llevar a cabo las pruebas de bucles simples
        • 3. Progresar hacia fuera, llevando a cabo pruebas para el siguiente bucle
        • 4. Continuar hasta que se hayan probado todos los bucles
      • Bucles concatenados:
      • Se pueden probar mediante el enfoque definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto.
      • Bucles no estructurados:
      • Esta clase de bucles se debe rediseñar para que se ajusten a las construcciones de programación estructurada.
    • PRUEBA DE CAJA NEGRA
      • Se centra en los requisitos funcionales del software.
      • Se trata de un enfoque complementario que intenta descubrir diferentes tipos de errores de los métodos de caja blanca.
      • La prueba de caja negra intenta encontrar errores de las siguientes categorías:
        • Funciones incorrectas o ausentes
        • Errores de interfaz
        • Errores es estructura de datos o en accesos a bases de datos externas
        • Errores de rendimiento
        • Errores de inicialización y de terminación
      • La prueba de Caja Negra tiende a aplicarse durante fases posteriores de la prueba, ya que centra su atención en el campo de la información.
    • Método de prueba basados en grafos
      • La prueba empieza creando un grafo de objetos y sus relaciones y después diseñando una serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y sus relaciones para descubrir los errores.
      • Estos casos de prueba están diseñados para intentar encontrar errores en algunas de las relaciones.
      • El grafo ayudaría a identificar aquellos bucles que hay que probar.
    • Partición equivalente
      • Es un método de prueba de caja negra, se dirige a la definición de casos de prueba que descubran clases de errores, reduciendo así el número total de casos de prueba que hay que desarrollar.
      • El objetivo de partición equivalente es reducir el posible conjunto de casos de prueba en uno más pequeño, un conjunto manejable que evalúe bien el software.
      • El diseño de casos de prueba para la partición equivalente se basa en una evaluación de las clases de equivalencia para una condición de entrada.
      • Una clase de equivalencia representa un conjunto de estados válidos o no válidos para condiciones de entrada (es un valor numérico específico, un rango de valores, un conjunto de valores relacionados o una condición lógica).
      • Sitio alquiler de películas
      • Rango de valores
        • Alquiler para personas mayores 18 años
      • Valor
        • Nº de películas que se alquilan
      • Conjunto de valores específico
        • Películas (Acción, Comedia, Infantil, Intriga)
      • Lógico
        • ¿Es socio?
    • Análisis de Valores Límite (AVL)
      • Es una técnica de diseño de casos de prueba que complementa la prueba de Partición Equivalente. En lugar de realizar la prueba con cualquier elemento de la partición equivalente, se escogen los valores en los extremos de la clase.
      • Por ejemplo: si una condición de entrada especifica un rango delimitado por los valores a y b, se deben diseñar casos de prueba para los valores a y b y para los valores que se encuentran por debajo y por encima.
    • Prueba de Comparación
      • Aplicación en sistemas de alta fiabilidad
      • Desarrollos paralelos
      • Intercambio de casos de prueba
      • Desarrollo del software, las versiones de la aplicación se ejecutan en equipos independientes, usando las mismas especificaciones.
      • Se deben probar todas las versiones con los mismos datos, para asegurar que proporcionan una salida idéntica.
      • Pruebas de interfaces gráficas de usuario
      • Prueba de documentación y de ayuda
        • Es importante para la aceptación del programa.
        • Revisar la guía de usuario o funciones de ayuda en línea.
      • Prueba de sistemas de tiempo real
        • Prueba de tareas
        • Prueba de comportamiento
        • Prueba intertareas
        • Prueba del sistema
      PRUEBA DE ENTORNOS Y APLICACIONES ESPECIALIZADAS
    • 6.2 Nivel de Pruebas
      • Pruebas de unidad : Mediante esta prueba sólo una unidad es probada como tal, como una clase, u paquete de servicio o un subsistema.
      • Pruebas de Integración: En ella se verifica que las unidades trabajen juntas correctamente.
      • Pruebas de Sistema: Verifica el sistema completo o su aplicación como tal. Se toma el punto de vista del usuario final y los casos de uso de pruebas.
    • PRUEBA DE UNIDAD
      • Pruebas de procedimientos o subrutinas. En
      • un sistema orientado a objetos se aplican en
      • un nivel más alto, a partir de las clases.
      • Una prueba de unidad consiste en una
      • prueba estructural (o caja blanca ), lo cual
      • requiere conocer el diseño interno de la
      • unidad, y una prueba de especificación(de
      • caja negra , basada sólo en la especificación
      • del comportamiento externamente visible de
      • la unidad.
    • PRUEBA DE UNIDAD
      • Prueba de Especificación o de Caja Negra: Tiene como propósito verificar las relaciones de entrada y salida de una unidad. Su objetivo es verificar que hace la unidad, pero sin averiguar como lo hace.
      • Prueba basada en estado: Verifica las interacciones entre operaciones de una clase según cambios en los atributos de un objeto. Es necesario hacer pruebas del objeto de acuerdo con su ciclo de vida .
      • Prueba Estructural o de Caja Blanca: Verifica que la estructura interna de la unidad sea correcta.
    • PRUEBA DE INTEGRACION
      • Después de haber probado todas las
      • unidades, éstas deben ser integradas en
      • unidades más grandes hasta generar el
      • sistema completo.
      • El propósito de la prueba de integración es
      • probar que las diferentes unidades trabajen
      • juntas de manera apropiada.
    • 7. Proceso de Pruebas
      • El proceso de pruebas involucra consideraciones
      • similares al del proceso de desarrollo, incluyendo
      • estrategias, actividades y métodos, los cuales
      • deben ser aplicados de manera concurrente con el
      • proceso de desarrollo de software.
        • 1. ESTRATEGIA DE LA PRUEBA :
      • Orden de Pruebas: Tienen como propósito definir en que momento y en que orden se aplicarán las pruebas. Diseño, implementación y operación del sistema.
    • 7. Proceso de Pruebas
      • ESTRATEGIA DE LA PRUEBA:
      • Orden de Pruebas: Existen dos enfoques generales para el orden en que se efectuarán las pruebas:
      • De arriba hacia abajo: Se deben desarrollar inicialmente las interfaces entre subsistemas, para probar protocolos de alto nivel antes de ir a probar los niveles inferiores.
      • De abajo hacia arriba: Certificar primero las unidades de bajo nivel y luego las interfaces entre ellos.
    • 7. Proceso de Pruebas
      • 1. ESTRATEGIA DE LA PRUEBA:
      • Alcance de pruebas: Tiene como propósito identificar el tipo, número y casos de pruebas que se aplicarán para revisar los diferentes aspectos del sistema
      • Automatización de la Prueba: Tiene como propósito reducir el esfuerzo y costo de las pruebas mediante automatización del proceso o aspectos de él.
    • 7. Proceso de Pruebas
      • 2. PLANEACION DE LA PRUEBA:
      • Comienza con el establecimiento de las estrategias
      • de pruebas, lo que incluye la cuestión si estás se
      • harán automática o manualmente y si existen
      • programas y datos de prueba que puedan ser
      • usados, posiblemente modificados o desarrollados
      • de nueva cuenta
      • Estrategia de la prueba
      • Alcance de la prueba
      • Recursos
    • 7. Proceso de Pruebas
      • 3. CONSTRUCCION DE LA PRUEBA:
      • Se describe cada prueba y su propósito de manera
      • general y detallada. Se debe describir exactamente
      • cómo se deberá ejecutar el caso de prueba, de
      • manera que personas no familiarizadas con la
      • aplicación puedan ejecutar el caso.
      • Ambiente de desarrollo o real
      • Tipo de software
      • Tipo de hardware
      • Equipo de prueba
      • Versión del sistema
    • 7. Proceso de Pruebas
      • 3. EJECUCION DE LA PRUEBA:
      • Durante esta etapa se utiliza la especificación del diseño de prueba y los reportes de ésta.
      • La estrategia es aplicar de manera paralela el mayor caso de pruebas posibles.
      • Se Ejecutan las pruebas automáticas y manuales de manera correspondiente y se indican los resultados esperados.
      • Si alguna prueba falla, se interrumpe su aplicación y se anota el resultado para luego analizar el defecto y corregirlo.
    • JTS 2008
      • V JORNADA DE TESTEO DE SOFTWARE 2008
      • 2,3 Y 4 DE ABRIL DE 2008
      • VALENCIA ESPAÑA
      • VIDEO
      • BLOG DE LA JORNADA
    • BIBLIOGRAFIA
      • Ingenieria de Software Orientada a Objetos.-Alfredo Weitzenfeld.- Editorial Thomson