Plan maestro de validación

Conceptos (2) Unidad II
Llevar a cabo la V&V sólo luego de que se dispone del código final, hace que sea muy difícil y costoso reparar los errores detectados. Todo debe ser V&V: cualidades, subproductos, proceso, la misma V&V, etc. Los resultados pueden no ser binarios:
La presencia de defectos en el soft industrial no puede evitarse por completo en la práctica En ocasiones algunos defectospueden tolerarse En la práctica, la corrección es relativa

Verificación de Software

Aun las cualidades implícitas deben V&V.

Conceptos
Validación. ¿Estamos fabricando el producto correcto? Programa → usuario Verificación. ¿Estamos fabricando correctamente el producto? Programa → especificación Todas las actividades que se emprenden para asegurar que el software cumple sus objetivos” Sededuce que tanto el proceso como el producto deben ser V&V.

Técnicas de V&V
Verificación formal de programas y modelos Testing Simulación Chequeo de modelos (model checking) Construcción formal de programas

Técnicas de V&V (2)
Poner a prueba un programa puede usarse para mostrar la presencia de errores, pero nunca para mostrar su ausencia. Las técnicas estáticas pueden usarse sólo parachequear la correspondencia entre el soft y la especificación; no pueden probar que el soft es operacionalmente correcto. Verificación de modelos es una técnica automática para verificar sistemas reactivos modelados con FSM y especificados con fórmulas de una lógica temporal proposicional.

Planificación de V&V (2)
Ingeniería de requerimientos Arquitectura Diseño y especificación de módulos Diseñodetallado

Plan de validación

Plan de verificación de integración

Plan de verificación de componentes

Validación

Verificación de integración

Verificación de componentes

Planificación de V&V
Verificación de componentes

Planificación de V&V (3)
Localizar el error Diseñar la corrección del error Corregir el error Volver a verificar

Verificación de unidades

Verificación demódulos Validación

Verificación de sub−sistemas

Verificación del sistema
Verificación de integración

Vocabulario (2)

Testing estructural

Dado un programa P y un caso de prueba d para P, decimos que P es correcto en d si P(d) es la salida esperada para P cuando ejecuta d. Dado un programa P y un conjunto de prueba T, decimos que P es correcto en T si P es correcto para todo d enT. Un criterio o táctica de selección de pruebas (criterio de prueba, criterio o táctica) es una regla, procedimiento o algoritmo que permite calcular conjuntos de prueba para cualquier programa.

Vocabulario
Llamamos dominio de un programa al producto cartesiano entre los tipos de datos de las variables de entrada.
¿Funciones parciales o totales?

Vocabulario (3)
Los criterios se basan endividir el dominio de un programa en clases de equivalencia, Di , con la esperanza de que el programa se comporte igual para todo d en Di . Un criterio C es más fino que otro criterio C’ sii para todo programa P y todo conjunto de prueba T de P que satisface C, existe un subconjunto de T que satisface C’ para P.

Dado un programa P con dominio D un caso de prueba para P es un elemento dperteneciente a D. Dado un programa P con dominio D un conjunto de casos de prueba (o conjunto de prueba) para P es cualquier subconjunto de D.

Testing estructural
Esta forma de testing utiliza la información sobre la estructura interna del programa. Testing de caja blanca. Se prueba lo que el programa hace y no lo que se supone que hace. Un criterio para testing estructural se define indicando deforma genérica un subconjunto de caminos que deben recorrerse.
Cualquier conjunto de prueba que logre recorrer todos esos caminos satisface el criterio.

Cubrimiento de sentencias
Seleccionar T tal que, al ejecutar P para cada d en T, cada sentencia elemental de P es ejecutada al menos una vez. Un error no puede descubrirse si la parte donde está no es probada. No siempre que se ejecute una...