Verificacion y Validacion

  • View
    111

  • Download
    1

Embed Size (px)

Transcript

  • TECNOLOGICO DE ESTUDIOS SUPERIORES DE

    COACALCO

    ING. EN SISTEMAS COMPUTACIONALES

    VALIDACION Y VERIFICACION

    UNIDAD 2: PRUEBAS

  • ndice

    2.1 Tipos de pruebas ............................................................................................... 3

    2.2 Coberturas de las pruebas ................................................................................ 5

    2.3 Preparacin de las pruebas ............................................................................... 7

    2.5 Criterios para la realizacin de pruebas ............................................................ 8

    2.6 Plan de pruebas (verificacin y validacin) ....................................................... 8

    2.7 Estructura de los casos de prueba .................................................................. 10

    2.8 Conceptos generales de los diseos de las pruebas (verificacin y validacin)

    .............................................................................................................................. 10

    2.9 Reporte y seguimiento de errores ............................................................... 11

    2.10 Informe de las pruebas ................................................................................ 12

    2.11 Fuentes de informacin de QA para el control estadstico o mtrico ............ 14

    2.13 Importancia de la calidad, mtricas y control estadstico............................... 15

    Conclusiones ......................................................................................................... 16

    Referencias ........................................................................................................... 16

  • 2.1 Tipos de pruebas

    Existen dos tipos diferentes de prueba, que se utilizan en las diferentes etapas de

    desarrollo del software:

    Las pruebas de defectos: Pretenden encontrar las inconsistencias entre un

    programa y su especificacin. Estas inconsistencias se deben habitualmente a los

    fallos o defectos en el cdigo del programa. Las pruebas se disean para revelar la

    presencia de defectos en el sistema, ms que para evaluar su capacidad

    operacional.

    Las pruebas estadsticas: se utilizan para probar el desempeo y la fiabilidad del

    programa y comprobar cmo trabaja bajo condiciones operacionales. Las pruebas

    se disean para reflejar las entradas de los usuarios y su frecuencia.

    Despus de llevar a cabo las pruebas, se puede hacer una estimacin de la

    fiabilidad operacional del sistema contando el nmero de cadas observadas en el

    sistema. La capacidad del programa se valora midiendo el tiempo de ejecucin y el

    tiempo de respuesta del sistema cuando procesa los datos estadsticos de la

    prueba.

    No existe una separacin clara entre estos dos tipos de pruebas. Durante las

    pruebas de defectos los desarrolladores obtienen una visin intuitiva de la fiabilidad,

    y durante las pruebas estadsticas, se descubren obviamente muchos fallos.

    El objetivo de las pruebas de defecto es detectar los defectos latentes de un sistema

    software antes de entregar el producto.

    --Una prueba de defectos exitosa es aquella que descubre un fallo, esto es, un

    comportamiento contrario a la especificacin.

    --Las pruebas de defectos demuestran la existencia de un fallo, y no la ausencia de

    cualquier fallo.

    Las pruebas exhaustivas no son posibles y deben sustituirse por subconjuntos de

    casos de prueba. Se deben establecer polticas para establecer esos casos de

    prueba. Por ejemplo:

    --Que todas las instrucciones del programa se ejecuten al menos una vez

    --Se deben probar todas las funciones del sistema que se acceden a travs de

    men.

  • --Si la entrada es introducida por el operador, todas las funciones deben probarse

    con entradas correctas e incorrectas.

    Pruebas funcionales (Caja negra) Las pruebas funcionales o de caja negras

    es una poltica de seleccin de casos de pruebas basado en la especificacin del

    componente o programa.

    Las pruebas se seleccionan en funcin de la especificacin y no de la estructura

    interna del software.

    Las pruebas funcionales o de caja negra son una estrategia para seleccionar las

    pruebas de fallos basndose en las especificaciones de los componentes y

    programas, y no del conocimiento de su implementacin. El sistema se considera

    como una caja negra cuyo comportamiento slo se puede determinar estudiando

    las entradas y de contrastarlas con las respuestas que proporciona el sistema.

    Pruebas estructurales (Caja blanca) En las pruebas estructurales las pruebas

    se seleccionan en funcin del conocimiento que se tiene de la implementacin del

    mdulo.

    Se suelen aplicar a mdulos pequeos. El probador analiza el cdigo y deduce

    cuntos y qu conjuntos de valores de entrada han de probarse para que al menos

    se ejecute una vez cada sentencia del cdigo. Se pueden refinar los casos de

    prueba que se identifican con pruebas de caja negra.

    Pruebas de integracin Se prueban la respuesta de grupos de mdulos

    interconectados a fin de detectar fallos resultantes de la interaccin entre los

    componentes.

    Las pruebas de integracin se realizan con referencia a las especificaciones del

    programa.

    La principal dificultad de las pruebas de integracin es la localizacin de los fallos.

    Para facilitar la deteccin de los errores se utilizan tcnicas incrementales.

    --Una vez que se han probado los componentes individuales del programa, deben

    integrarse para crear un sistema parcial o completo. En el proceso de integracin

    hay que probar el sistema resultante con respecto a los problemas que surjan de

    las interacciones de los componentes.

    --Las pruebas de integracin se desarrollan a partir de la especificacin del sistema

    y se inician tan pronto como estn disponible versiones utilizables de algunos

    componentes del sistema.

  • 2.2 Coberturas de las pruebas

    Uno de los principales problemas a la hora de realizar las pruebas de un sistema es

    el gran nmero de casos de prueba necesarios para obtener una seguridad de que

    el sistema bajo prueba funciona correctamente, o con otras palabras, tener un

    conjunto de casos de prueba con la calidad suficiente para estar seguros que el

    programa bajo prueba funciona correctamente.

    Un criterio de cobertura se puede entender segn M. Broy et al. Con dos significados

    diferentes:

    - Como un criterio de adecuacin, el cual sirve para determinar cundo un conjunto

    de casos de prueba tiene la calidad suficiente, por lo que el sistema bajo prueba

    que probado correctamente

    - Como un criterio de seleccin el cual nos sirve para aadir casos de prueba nuevos

    a nuestro conjunto de casos de prueba y de esta manera mejorar la calidad del

    mismo.

    Ambos significados dan la idea de que los criterios de cobertura son interesantes

    para medir la calidad de los conjuntos de casos de prueba. Dentro del mbito de las

    pruebas de caja blanca, las cuales tienen en cuenta la estructura interna del

    programa bajo prueba para comprobar el correcto funcionamiento del mismo, los

    criterios de cobertura se pueden clasificar en base a los siguientes tres aspectos:

    Los criterios estructurales se usan para medir la calidad de un conjunto de casos de

    prueba. Esta calidad se mide en funcin del porcentaje alcanzado en funcin del

    criterio que se haya escogido. Como su propio nombre indica, estos criterios s

    definen en base a la estructura del programa bajo prueba, por ejemplo, si tenemos

    una mquina de estados, un criterio estructural podra definirse en funcin de los

    estados de la misma o en funcin de las transiciones. Una clasificacin bastante

    aceptada de los diferentes criterios de cobertura para las pruebas de caja blanca,

    es clasificar estos criterios en dos grandes grupos: criterios basados en el flujo de

    control y criterios basados en flujo de datos.

    Criterios de cobertura basados en el flujo de control este tipo de criterios estn

    basados en las expresiones lgicas introducidas en la especificacin del sistema

    bajo prueba que determinan cuando existen saltos o bucles dentro de la

    implementacin, en otras palabras, se basa en las condiciones de las estructuras If-

    THENELSE y los LOOP que existe dentro de la implementacin del sistema. Los

    criterios de cobertura de este tipo ms usados son los siguientes:

  • El criterio de cobertura de sentencias, es el criterio ms simple de todos, define

    que han de recorrerse todas las lneas o sentencias del cdigo del programa al

    menos una vez.

    El criterio de cobertura de decisiones o cobertura de ramas expuesto por primera

    vez en requiere que cada posible valor (verdadero o falso) que pueda tomar cada

    una de las decisiones del sistema bajo prueba se d al menos una vez, sabiendo

    que una decisin es un conjunto de condiciones relacionadas mediante operadores

    lgicos (and, or) y una condicin es un conjunto de expresiones algebraicas

    relacionadas con operadores relacionales (=).

    El siguiente criterio es la cobertura de condiciones, el cual requiere que cada

    condicin de cada decisin tome todos los posibles valores al menos una vez.

    Siguiendo con el ejemplo anterior, en este caso necesitaramos dos casos de

    prueba, uno que evale A Falso y B verdadero y otro A Verdadero, y B Falso. A

    pesar de que este crite