PDF de programación - Programación II - Tema 3. Verificación de programas

Programación II
Bloque temático 1. Lenguajes de programación
Bloque temático 2. Metodología de programación

Tema 2.

Programación dirigida por eventos
Tema 3. Verificación de programas

Bloque temático 3. Esquemas algorítmicos

Programación II

Tema 3. Verificación de programas

© Mario Aldea Rivas

25/03/11

Tema 3. Verificación de programas
3.1. Verificación y Validación
3.2. Pruebas del software
3.3. Caja negra: particiones de equivalencia
3.4. Herramienta JUnit
3.5. Prueba de estados
3.6. Bibliografía



1



Programación II

Tema 3. Verificación de programas

3.1 Verificación y Validación

© Mario Aldea Rivas

25/03/11

2

3.1 Verificación y Validación

VyV (o V&V): procesos de comprobación y análisis para tratar de
asegurar que el software esté acorde con sus requisitos y cumpla
las necesidades de los clientes
• Verificación: ¿estamos construyendo el producto

correctamente?
• conjunto de actividades que aseguran que el software cumple

sus requisitos (hace lo que se supone que tiene que hacer)

• Validación: ¿estamos construyendo el producto correcto?
• conjunto (diferente) de actividades que aseguran que el

software construido se corresponde con los requisitos reales
del cliente

Programación II

© Mario Aldea Rivas

25/03/11

3

Tema 3. Verificación de programas

Ejemplo de Verificación y Validación

3.1 Verificación y Validación

VyV de un programa que permite gestionar los alumnos
matriculados en los cursos de una academia
Verificación:

• ¿las operaciones de gestión de las listas de alumnos funcionan

correctamente?

• ¿las operaciones de gestión de cursos funcionan

correctamente?

Validación:

• ¿El programa proporciona todas las operaciones que el usuario

necesita?

• ¿Las operaciones hacen lo que el usuario espera?
• ¿La interfaz con el usuario es la apropiada?

Programación II

Tema 3. Verificación de programas

© Mario Aldea Rivas

25/03/11

4

3.1 Verificación y Validación

Técnicas de Verificación y Validación

El proceso VyV utiliza dos técnicas de comprobación y análisis:
• Inspecciones del software:

• revisión sistemática de todos los documentos generados en el
proceso de desarrollo del software (requisitos, diseño, código)

• es una técnica estática: no se necesita que el sistema se

ejecute

• Pruebas del software:

• contrasta la respuesta del sistema con los resultados

esperados

• es una técnica dinámica: se necesita ejecutar el sistema

completo (o al menos un prototipo o alguna de sus partes)

Programación II

Tema 3. Verificación de programas

Depuración

© Mario Aldea Rivas

25/03/11

5

3.1 Verificación y Validación

• VyV: proceso que permite detectar la existencia de defectos
• Depuración: proceso que localiza y corrige esos defectos

• es un proceso difícil: los defectos no siempre se detectan cerca

del punto que los provocó

• suele ser necesario diseñar programas de prueba que permitan

repetir y observar el defecto
• se utilizan los depuradores

Después de corregir un defecto es necesario volver a probar el
sistema (pruebas de regresión)

• para detectar nuevos fallos introducidos al tratar de corregir un

defecto (“regresiones”)

• lo ideal sería repetir todas las pruebas, cuando es muy costoso

se repiten únicamente las relacionadas con el fallo corregido

Programación II

© Mario Aldea Rivas

25/03/11

6

Tema 3. Verificación de programas

Realización de las pruebas

3.1 Verificación y Validación

Se debe probar con la mayor frecuencia que sea posible
Hay que dedicar los suficientes recursos:

• las pruebas suelen ser más costosas que el propio programa

Importancia del informe de pruebas:

• debe permitir comparar con resultados anteriores para detectar

posibles regresiones

Ejemplos:

• Compilador GNAT: probado 2 veces al día en decenas de
computadores, miles de programas de prueba, se prueban
todas las configuraciones posibles y todas las arquitecturas

• MaRTE OS: probado 2 veces al día, se prueban todas las
arquitecturas, 4000 programas de prueba, tardan 2 horas

Programación II

Tema 3. Verificación de programas

3.2 Pruebas del software

© Mario Aldea Rivas

25/03/11

3.2 Pruebas del software

Las pruebas se realizan en cuatro etapas:

1.Prueba de componentes (prueba de métodos y clases)

- se prueba cada método y clase de forma independiente

2.Prueba de integración o de subsistemas

- se prueban agrupaciones de clases relacionadas

3.Prueba de sistema

- se prueba el sistema como un todo

4.Prueba de validación

- prueba del sistema en el entorno real de trabajo
- con intervención del usuario final

El descubrimiento de un defecto en una etapa requerirá la
repetición de las etapas de prueba anteriores

Programación II

Tema 3. Verificación de programas

© Mario Aldea Rivas

25/03/11

Tipos de pruebas de software

3.2 Pruebas del software

7

8

• Pruebas de defectos

• Buscan diferencias entre lo que el programa hace y lo que

debería hacer (su especificación)

• Una prueba exitosa es la que descubre un defecto
• Sirven para demostrar la presencia, no la ausencia, de defectos

• Pruebas estadísticas

• Miden la fiabilidad (número de caídas por unidad de tiempo) y

los tiempos de respuesta del sistema

• Se realizan exponiendo el programa a la misma carga de trabajo

que soportará en su entorno final

Nos centraremos en las pruebas de defectos realizadas durante la
prueba de componentes en sistemas orientados a objetos

Programación II

© Mario Aldea Rivas

25/03/11

9

Tema 3. Verificación de programas

Prueba de defectos en componentes (clases)
Idealmente se realiza en dos fases:

3.2 Pruebas del software

1.Prueba de métodos:

- se analiza el resultado de ejecutar cada método bajo distintas
condiciones (distintos valores de los parámetros de entrada
y de los atributos de la clase)

2.Prueba de estados:

- se analiza la evolución del estado de la clase (valor de sus
atributos) bajo distintas combinaciones de llamadas a sus
métodos

Normalmente ambas fases no son independientes:

• probar un método bajo distintas condiciones requiere llevar al

objeto a distintos estados (invocando otros métodos)

• p.e. la operación “busca” de una lista debería probarse cuando

la lista esté vacía y cuando contenga elementos

Programación II

Tema 3. Verificación de programas

Prueba de métodos

© Mario Aldea Rivas

25/03/11

10

3.2 Pruebas del software

Principales mecanismos para la prueba de métodos:

• Pruebas funcionales o de “caja negra”

- los casos de prueba se basan en la especificación del método
- no se requiere conocimiento de su estructura interna
- no es necesario disponer del código fuente

• Pruebas estructurales o de “caja blanca” o “caja de cristal”

- los casos de prueba se seleccionan en función del

conocimiento que se tiene de la estructura del método

- es necesario disponer del código fuente

No se trata de técnicas alternativas, más bien enfoques
complementarios que permiten detectar distintos tipos de errores

Programación II

Tema 3. Verificación de programas

© Mario Aldea Rivas

25/03/11

11

3.3 Caja negra: particiones de equivalencia

3.3 Caja negra: particiones de equivalencia

En general es imposible probar un método para todas las
combinaciones posibles de entradas
En lugar de eso los datos de entrada se dividen en particiones de
equivalencia:

• conjunto de datos de entrada que se espera que tengan un

comportamiento equivalente

Los casos de prueba se eligen en función de las particiones:

• se elige un caso central por partición: caso típico
• se elige casos correspondientes a las fronteras con otras

particiones: casos atípicos

Las particiones se identifican utilizando la especificación del
método y nuestra propia experiencia

Programación II

© Mario Aldea Rivas

25/03/11

12

Tema 3. Verificación de programas

3.3 Caja negra: particiones de equivalencia

Ej.: particiones de equivalencia con caja negra
Especificación de un método de búsqueda:
método Busca(Elemento ele, Elemento[] t)

retorna Booleano encontrado, Entero pos
{Pre: longitud de t > 0}
busca elemento en tabla
{Post:(t[pos]=ele & encontrado=true) |

(ele no en t & encontrado=false) |
(eleva excepción SECUENCIA_VACÍA)}

fmétodo
Particiones de equivalencia

• “el elemento está en la secuencia” / “el elemento no está en la

secuencia”

• “secuencia vacía” / “la secuencia tiene un elemento” / “la

secuencia tiene más de un elemento”

Programación II

Tema 3. Verificación de programas

© Mario Aldea Rivas

25/03/11

13

3.3 Caja negra: particiones de equivalencia

Ej.: particiones de equivalencia con caja negra (cont.)

Criterios de prueba generales para tablas:

• utilizar tablas de distintos tamaños
• acceder a los elementos primero, central y último

Casos de prueba basados en las particiones y los criterios:

Elección del caso de

prueba

Secuencia vacía
Secuencia de un

elemento

Frontera entre uno y más

elementos

Secuencia de más de un
elemento: encontrado

(primero, central y

último) y no encontrado

Programación II

Tema 3. Verificación de programas

Casos de prueba

t

vacía
17
17

17, 18
11, 4

17, 29, 21, 23

41, 18, 9, 31, 30, 16, 45
17, 18, 21, 23, 29, 41, 38

21, 23, 29, 33, 38

Salida esperada
pos

encontrado

excepción
true
false
true
false
true
true
true
false

0
-
1
-
0
6
3
-

ele
20
17
18
18
1
17
45
23
25

© Mario Aldea Rivas

25/03/11

14

3.4 Herramienta JUnit
• JUnit es una herramienta de código abierto que permite ejecutar

3.4 Herramienta JUnit

conjuntos de pruebas de forma rápida y sistemática
• integrada en el entorno Eclipse
• para prueba de clases
• http://www.junit.org

• Pensada para realizar pruebas repetidamente cada vez que se

realiza un pequeño cambio en el código:

- siguiendo el lema de la metodología Extreme Programming

(XP): “Code a little, test a little”.

• Configuración del proyecto para usar JUnit:
1.Botón derecho del ratón sobre el proyecto y elegir: Build
Path => Configure Build Path
2.En la ficha Libraries elegir Add Library, seleccionar JUnit
y pulsar Next,