1. OBJETIVOS

   
   

El objetivo de este tema es introducir la verificación y validación del software con énfasis en las técnicas de verificación estáticas y en la prueba dinámica del código. Objetivo de este tema son:

• Comprender las diferencias entre verificación y validación del software
• Valorar la inspección del software en el análisis estático como métodos de descubrir fallos y mejoras de calidad del software.
• Conocer las técnicas de pruebas para descubrir fallos en el código
• Analizar las técnicas específicas para las pruebas de componentes y pruebas de sistemas orientados a objetos
• Importancia de las herramientas CASE para la verificación del software y apoyar al desarrollo de pruebas.

• Verificación y Validación

Verificación

• Descubrir defectos (para corregirlos)
• provocar fallas (una forma de detectar defectos)
• revisar los productos (otra forma de detectar defectos)
• evaluar la calidad de los productos  el probar o revisar el software da una idea de la calidad del mismo

«Verificar significa demostrar formalmente que un programa satisface su especificación.»

La verificación se puede realizar mediante análisis, pruebas o una combinación de ambos. Las actividades podrían incluir:

• Revisión del documento de todas  las fases del ciclo de vida de seguridad para garantizar el cumplimiento con los objetivos y requisitos.
• Revisión del diseño
• Pruebas de los productos diseñados para garantizar que funcionen de acuerdo con su especificación. Esto es especialmente valioso para componentes modulares – tales como el código para un algoritmo de votantes- que se usara muchas veces.
• Pruebas de integración realizadas cuando se juntan diferentes partes del sistema.

Validación

La validación comprueba si lo que se ha especificado e implementado es lo que el usuario realmente desea, es decir, si responde a la pregunta: ¿se ha construido el software correcto? 

• El proceso determina si el software cumple su especificación. 
• El proceso asegura que el software fabricado se comporta como se espera y de acuerdo a las expectativas del cliente.

Otro factor a tener en cuenta es la a independencia del proceso de V&V, ya que es una característica reconocida como altamente positiva en distintas áreas, reportando dentro del desarrollo software una serie de características importantes: 

• La separación de intereses, por la cual se evitan conflictos de intereses internos en una organización. Una organización independiente garantiza que requisitos importantes no sean ignorados en el proceso de toma de decisiones. 
• La diferenciación de puntos de vista, esto supone una segunda opinión, que siempre es interesante para eliminar ambigüedades u omisiones.
• La efectividad y la productividad, las actividades de V&V son llevadas a cabo por personal experto, con competencias específicas en el área de V&V.

• TECNICAS DE VERIFICACION Y VALIDACION

TECNICAS ESTATICAS:

Las revisiones del software se pueden dividir en tres categorías: 

1. Las revisiones de par del software

   1. Las revisiones de la gerencia del software

   2. Las revisiones de la intervención del software

Las revisiones informales

• La revisión del código

• La programación en parejas

Las revisiones formales

• Planificación

  • • Familiarización

    • Preparación

    • Examen

    • Rehacer

    • Seguimiento

A continuación se presentan una serie de revisiones que cumplen con la secuencia de actividades propuesta por Fagan, las cuales difieren unas de otras principalmente en el grado de aplicación de cada fase:

• Las inspecciones evalúan el código de sentencia en sentencia

  • • Los guías son inspecciones

    • La revisión técnica del software es una forma de revisión de par

    • Las auditorias son un tipo de revisión del software

TÉCNICAS DINÁMICAS

• Caja Negra (Funcional):

  Las técnicas de caja negra se distinguen porque los casos de prueba se basan sólo en el comportamiento de entrada/salida, diferenciándose:

  1. Las fragmentaciones equivalentes

     . 

  2. El análisis de los valores límite

• Caja Blanca (Estructural):

  Las técnicas de caja blanca se encuentran basadas en la información de cómo el software ha sido diseñado, entre ellos: 

  1. Los criterios de cobertura

     :

     • La cobertura de sentencias, por la cual cada sentencia se ejecuta al menos una vez.
     • La cobertura de decisiones, por la cual cada decisión tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso.
     • La cobertura de condiciones, por la cual cada condición de cada decisión adopte el valor verdadero al menos una vez y el falso al menos una vez.
     • El criterio de decisión/condición, por el cual se cumplan a la vez el criterio de condiciones y el de decisiones.
     • El criterio de condición múltiple, por la cual la evaluación de las condiciones de cada decisión no se realiza de forma simultánea. 

  2. Los grafos de flujo

     1. Las pruebas del sistema

     2. Las pruebas de integración

     3. Las pruebas de entregas

     4. Las pruebas de componentes         

Las pruebas de componentes o pruebas unitarias son el proceso de prueba de los componentes individuales del sistema. Existen diferentes tipos de elementos que pueden ser objeto de prueba: 

• Los métodos o funciones individuales dentro de un objeto son el tipo más simple de componente, y sus pruebas son un conjunto de llamadas a dichas rutinas con diferentes parámetros de entrada. Las pruebas unitarias consisten en encontrar errores basándose en la estructura o en las especificaciones, verificando el funcionamiento individual de partes del software. 
  • • Las clases de objeto que tienen varios atributos y métodos, para las cuales se deberían diseñar las pruebas con el fin de proporcionar cobertura para todas las características del objeto, incluyendo pruebas aisladas de todas sus operaciones asociadas, la consulta de sus atributos y la ejecución de sus distintos estados. 
    • Los componentes compuestos formados por diferentes objetos o funciones, los cuales poseen una interfaz definida utilizada para acceder a su funcionalidad. Las pruebas se ocuparan principalmente de demostrar que se comportan conforme a su especificación.

• INSPECCIÓN DEL SOFTWARE

• Se analizan las diferentes representaciones del sistema (diagramas de requerimientos, diagramas de diseño y código fuente) en búsqueda de defectos.
• Son Técnicas de Validación estáticas No requieren que el código se ejecute
• Debe realizarse durante todo el ciclo de desarrollo

Por lo tanto, para validar un sistema de software, siempre se requieren llevar a cabo ciertas pruebas. Aunque en la actualidad las inspecciones se utilizan ampliamente, las pruebas de los programas es aún la técnica de verificación y validación predominante. 

• Las inspecciones se pueden aplicar a la detección de fallos en cualquiera de los documentos generados
•  Permiten detectar entre un 60 y un 90% de los fallos a unos costes mucho más bajos que las pruebas dinámicas.
• Permiten detectar múltiples defectos en una simple inspección, mientras que las pruebas solo suelen detectar un fallo por prueba.
• Permite utilizar el conocimiento del dominio y del lenguaje, que determinan los principales tipos de fallos que se suelen cometer.
• Las inspecciones son útiles para detectar los fallos de módulos, pero no detectan fallos a nivel de sistema, que ha de hacerse con pruebas.
• Las inspecciones no son útiles para la detección de niveles de fiabilidad y evaluación de fallos no funcionales.

  1. Inspección del código fuente: Análisis estático automatizado

• Los analizadores estáticos de programas son herramientas de software que rastrean el texto fuente de un programa, en busca de errores no detectados por el compilador.
• En algunos lenguajes de programación no son muy útiles pues el compilador ofrece una gran información acerca de posibles errores (incluso en ejecución).
• Aspectos habitualmente analizados son:
  1. Análisis de flujo de control: Identifica y señala los bucles con múltiples puntos de salida y las secciones de código no alcanzable.
  2. Análisis de utilización de datos: Señala como se utilizan las variables del programa: Variables sin utilización previa, que se declaran dos veces, declaradas y nunca utilizadas. Condiciones lógicas con valor invariante, etc.
  3. Análisis de interfaces: Verifica la declaración de las operaciones y su invocación. Esto es inútil en lenguajes con tipado fuerte (Java, Ada) pero si en los restantes (C no comprueba los parámetros de una operación.
  4. Análisis de la trayectoria: Identifica todas las posibles trayectorias del programa y presenta las sentencias ejecutadas en cada trayectoria.
  5. Debe utilizarse siempre junto a inspecciones directas del código, pues existen errores que no pueden detectar, por ejemplo la inicialización de una variable a un valor incorrecto

• PROCESOS DE DEPURACIÓN

• Proceso que localiza y corrige los errores descubiertos durante la verificación y validación.
• Es un proceso complicado pues no siempre los errores se detectan cerca del punto en que se generaron.
• Se utilizan herramientas de depuración, que facilitan el proceso
• Después de reparar el error, hay que volver a probar el sistema (pruebas de regresión).
• La solución del primer fallo puede dar lugar a nuevos fallos.

Al proceso de eliminación de los errores que se descubren durante las fases de prueba se denomina depuración. Es un proceso independiente que no tiene por qué estar integrado:

• La verificación y validación establece la existencia de defectos en el programa.
• La depuración es el proceso que localiza el origen y corrige estos defectos.

• LISTA DE FALLOS

  1. Fallos de datos:

  2. Fallos de control:

  3. Fallos de entrada/salida:

  4. Fallos de la interfaz:

  5.   
     

     Fallos de gestión de almacenamiento:

  6.  
     

     Fallos de gestión de las excepciones

1. VALIDACIÓN EN CMMI DEV V1.3

El área de proceso deValidación corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito demostrar que un producto o componente de producto se ajusta a su uso previsto cuando se sitúa en su entorno previsto.

1. Validación en ITIL V3

La Validación y Pruebas del Servicio se relaciona con los siguientes procesos del Ciclo de Vida:

• La Gestión del Catálogo

• La Gestión de Niveles de Servicio

• La Planificación y Soporte de la Transición y la Gestión de Cambios

• La Gestión de Entregables y Despliegues

• Evaluación

  1. Validación, planificación y verificación de test

  2. Construcción de tests

  3. Pruebas

Las principales actividades realizadas en el subproceso de pruebas deben incluir:

• Pruebas del correcto funcionamiento de la versión.
• Pruebas de los procedimientos automáticos o manuales de instalación.
• Pruebas de los planes de back-out.
• Pruebas por grupo objetivo (roles), para medir la utilidad del servicio.

Siempre que sea posible, las pruebas de carácter funcional deben ser realizadas por un selecto grupo de usuarios finales. Durante este proceso de prueba se documentará y analizará:

• La experiencia subjetiva del usuario.
• Los comentarios y sugerencias sobre usabilidad y funcionalidad o las dudas que hayan surgido durante el uso de la nueva versión.
• La claridad de la documentación que se pondrá a disposición del usuario final.

1. Aceptación y reporte

Este documento incluye:

• Reporte de actividades realizadas.
• Listas de bugs o errores detectados, si se diera el caso.
• Ideas de mejora, que se envían a la fase de CSI.
• Información y conocimiento para el SKMS.

  1. Limpieza y cierre

  2. Control del proceso

La eficacia de la Validación y Pruebas del Servicio puede ser evaluada teniendo en cuenta los siguientes indicadores:

• Porcentaje de componentes que no superan los test de aceptación.
• Número de errores conocidos que se registran durante la etapa de pruebas.
• Tiempo de demora en la subsanación de errores.
• Número de incidentes atribuibles a las nuevas versiones.
• Porcentaje de test de aceptación del servicio que no obtienen la aprobación del cliente.

• PLANIFICACIÓN/PREPARACIÓN DE LAS PRUEBAS

Es la etapa en donde se ejecutan las primeras actividades correspondientes al proceso de pruebas y  tiene como resultado un entregable denominado plan de pruebas el cual debe estar conformado en cuando menos por aspectos tales como:

1. Alcance de la prueba

2. Tipos de Prueba

3. Estrategia de Pruebas

4. Criterios de Salida

5. Otros aspectos