slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE PowerPoint Presentation
Download Presentation
FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE

Loading in 2 Seconds...

play fullscreen
1 / 12

FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE - PowerPoint PPT Presentation


  • 202 Views
  • Uploaded on

FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE De hecho, las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo. Objetivos de las pruebas

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide2

FUNDAMENTOS DE LAS PRUEBAS DEL SOFTWARE

  • De hecho, las pruebas son uno de los pasos de la ingeniería del software que se puede ver (por lo menos, psicológicamente) como destructivo en lugar de constructivo.
    • Objetivos de las pruebas
    • La prueba es el 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.
  • ¿Cuál es nuestro primer objetivo cuando probamos el software?
  • Nuestro objetivo es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo.
slide3

PRINCIPIOS DE LAS PRUEBAS

    • A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del cliente.
    • Las pruebas deberían planificarse mucho antes de que empiecen.
    • El principio de Pareto es aplicable a la prueba del
  • software.
    • Las pruebas deberían empezar por «lo pequeño» y progresar hacia «lo grande»
    • No son posibles las pruebas exhaustivas.
    • Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente.
slide4

FACILIDAD DE PRUEBA

  • La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora.
  • La siguiente lista de comprobación proporciona un conjunto de características que llevan a un software fácil de probar.
    • Operatividad. «Cuanto mejor funcione, más eficientemente se puede probar.»
    • Observabilidad. Lo que ves es lo que pruebas.
    • Controlabilidad.«Cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.»
    • 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.»
    • 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.»
slide5

DISEÑO DE CASOS PRUEBA

El diseño de pruebas para el software o para otros productos de ingeniería puede requerir tanto esfuerzo como el propio diseño inicial del producto.

PRUEBA DE LA CAJA BLANCA

Denominada a veces prueba de caja de cristal.

Mediante los métodos de prueba de caja blanca, el ingeniero del software puede obtener casos de prueba que (1) garanticen que se ejercita por lo menos una vez todos los caminos independientes de cada módulo; (2) ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa; (3) ejecuten todos los bucles en sus límites y con sus límites operacionales; y (4) ejerciten las estructuras internas de datos para asegurar su validez.

slide6

PRUEBA DEL CAMINO BASICO

  • El método del camino básico permite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental.
    • Notación de grafo de flujo Cuando en un diseño procedimental se encuentran condiciones compuestas, la generación del gafo de flujo se hace un poco más complicada.
    • Complejidad ciclomática
  • La complejidad ciclomática es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa.
slide7

Obtención de casos de prueba

    • Usando el diseño o el código como base.
    • Determinamos la complejidad ciclomática del grafo de flujo resultante
    • Determinamos un conjunto básico de caminos linealmente independientes.
    • Preparamos los casos de prueba.
  • Matrices De Grafos:
  • En la figura, cada nodo del grafo de flujo está identificado por un número, mientras que cada arista lo está por su letra. Se sitúa una entrada en la matriz por cada conexión entre dos nodos.
slide8

PRUEBA DE LA ESTRUCTURA DE CONTROL

    • Prueba de condición’
  • La prueba de condición es un método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en el módulo de un programa.
    • Prueba del flujo de datos
  • El método de prueba depujo 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.
    • Prueba de bucles
  • La prueba de bucles es una técnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles. Se pueden definir cuatro clases diferentes de bucles: bucles simples, bucles concatenados, bucles anidados y bucles no estructurados.
slide9

PRUEBA DE CAJA NEGRA

  • Permite obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa.
    • Métodos de prueba basados en grafos: La prueba del software empieza creando un grafo de objetos importantes 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.
    • Partición equivalente: Divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.
    • Análisis de valores límite: Por razones que no están del todo claras, los errores tienden a darse más en los límites del campo de entrada.
    • Prueba de comparación: Hay situaciones (por ejemplo, aviónica de aeronaves, control de planta nuclear) en que la fiabilidad del software es algo absolutamente crítico.
    • Ejemplo: Una vista geométrica de
  • los casos.
slide10

PRUEBA DE ENTORNOS ESPECIALIZADOS, ARQUITECTURA Y APLICACIONES

1.Prueba de interfaces gráficas de usuario (IGUs)

Debido a los componentes reutilizables provistos como parte de los entornos de desarrollo de las GUI, la creación de la interfaz de usuario se ha convertido en menos costosa en tiempo ymás exacta.

2.Prueba de arquitectura cliente/servidor

La arquitectura cliente Servidor (C/S) representa un desafío significativo para los responsables de la pruebas del software. la necesidad de servir a múltiples clientes desde una base de datos centralizada (o en algunos casos, distribuida) y los requisitos de coordinación impuestos al servidor se combinan todos para hacer las pruebas de la arquitectura C/S

slide11

PRUEBA DE ENTORNOS ESPECIALIZADOS, ARQUITECTURA Y APLICACIONES

  • 3.Prueba de la documentación y facilidades de ayuda
  • Los errores en la documentación pueden ser tan destructivos para la aceptación del programa, como los errores en los datos o en el código fuente.
  • 4. Prueba de sistemas de tiempo-real
  • La naturaleza asíncrona y dependiente del tiempo de muchas aplicaciones de tiempo real, añade un nuevo y potencialmente difícil elemento a la complejidad de las pruebas , el tiempo.
  • Todavía han de evolucionar mucho los métodos generales de diseño de casos de prueba para sistemas de tiempo real. Sin embargo, se puede proponer una estrategia en cuatro pasos:
        • Prueba de tareas.
        • Prueba de comportamiento
        • Prueba intertareas
        • Prueba del sistema
slide12

CONCLUSIONES

    • El principal objetivo del diseño de casos de prueba es obtener un conjunto de pruebas que tengan la mayor probabilidad de descubrir los defectos del software.
    • Las pruebas de caja blanca se centran en la estructura de control del programa.
    • Las pruebas de caja negra son diseñadas para validar los requisitos funcionales sin fijarse en el funcionamiento interno de un programa.
    • Losmétodos de prueba especializados comprenden una amplia gama de capacidades del software y áreas de aplicación.