Introduccin al Proceso de

Pruebas.
Javier Gutirrez / javierj@us.es

Introduccin al proceso de pruebas

Objetivo: repasar las ideas
principales sobre las pruebas del
software y, en concreto, las que
usaremos para probar casos de uso.

ndice
1.
2.
3.
4.
5.

Introduccin a las pruebas.

Un resumen del proceso de prueba.
Niveles de prueba.
Pruebas de casos de uso.
Automatizacin de pruebas.

1. Introduccin a las pruebas.

Introduccin a las pruebas

Ariane 5.
Lanzado por primera vez el 4 de junio de
1996.
Ariane 5.
36.7 segundos despus explot.

Motivo:
Fallo software. La programacin no se haba probado lo suficiente.

Introduccin a las pruebas

Un reto a la

Sistemas software: Ingeniera de

Software.
Mayor tamao.
Mayor complejidad.
Menor tiempo de
desarrollo.
Mayor calidad.

Pruebas:
Ms importancia y
protagonismo da a da.
Garantizan la calidad del
software.
Garantizan la satisfaccin de
los requisitos.
Ahorran tiempo y recurso
en el desarrollo.
Su objetivo: localizar, para
subsanarlas, el mayor nmero
de deficiencias lo antes
posible.

Introduccin a las pruebas

Definicin de prueba:
Software testing consists of the
dynamic verification of the
behaviour of a program on a finite set
of test cases [].
Dynamic verification means that
testing always implies executing the
program on (valued) inputs.

Fuente: SWEBOK 2004

Introduccin a las pruebas

Definicin de prueba:
1

Verificacin dinmica del

comportamiento del software a
partir de un conjunto finito de
casos de prueba.
Validacin y Verificacin dos
conceptos muy relacionados:

Validacin: proceso de evaluar un

sistema o componente durante o al
final del proceso de desarrollo para
determinar si satisface los requisitos
especificados.
Verificacin: proceso de evaluar un
sistema o componente para
determinar si los productos de una
determinada fase satisfacen las
condiciones impuestas al comienzo
de la fase.
No implican ejecucin de cdigo.

Introduccin a las pruebas

Definicin de prueba:
Verificacin dinmica del
comportamiento del
software a partir de un
conjunto finito de casos de
prueba.

Para probar un programa

tenemos que ejecutarlo.
La prueba tiene un lmite.

No vale ejecutar el
programa de cualquier
manera.

Introduccin a las pruebas

Una prueba consta, al
menos, de tres
elementos:

Introduccin a las pruebas

Veamos un ejemplo sencillo:

Funciona el telfono?.
Valores de
prueba
123-45-67-89

Acciones
1. Descolgar auricular.
2. Marcar nmero de Pepote.
3. Esperar contestacin.

Resultado esperado
(Pepote): Digameee.

Introduccin a las pruebas

Veamos otro ejemplo sencillo:
Me est bien esta camisa?
Valores de
prueba
Mi cuerpo.

Acciones
1. Ponerme la camisa.
2. Abrochrmela.
3. Moverme un poco.
4. Mirarme al espejo.
Cuidado con la etiqueta o con arrugarla
por si hay que devolverla

Resultado esperado
Elegancia y confort.

Introduccin a las pruebas

Qu casos de prueba podemos escribir?.
public int suma(int a, int b)
{

Valores de
prueba

Acciones

Resultado
esperado

???

Suma(a, b)

???

return a + b;
}

Los casos de prueba son

finitos (y cuantos menos,
mejor).

Los casos de prueba buscan errores,

queremos el menor nmero que
encuentre los mximos errores.

Introduccin a las pruebas

Qu casos de prueba podemos escribir?.
public int suma(int a, int b)
{

Valores de
prueba

Acciones

Resultado
esperado

0, 0

Suma(a, b)

0, b = no 0

Suma(a, b)

return a + b;
}

3, 4

Suma(a, b)

-2, -8

Suma(a, b)

-10

-3, 6

Suma(a, b)

Integer.MAX_V
ALUE, 6

Suma(a, b)

3
-2147483643

Y algunas permutaciones ms.

Caractersticas de una buena prueba

Ha de tener una alta probabilidad de encontrar un
fallo. Cuanto ms, mejor.
No debe ser redundante. Si ya funciona, no lo
probamos ms.
Debe ser la mejor de la cosecha. Si tenemos
donde elegir, elegimos la mejor.
No debera ser ni demasiado sencilla ni demasiado
compleja. Si es muy sencilla no aporta nada, si es
muy compleja a lo mejor no sabemos lo que ha
fallado.

Un proceso de pruebas
Objetivos
Objetivosde
deprueba
prueba
Diseo
Diseode
decasos
casosde
de
prueba
prueba

Nuestro
Nuestroobjetivo
objetivo

Codif.
Codif.de
decasos
casosde
de
prueba
prueba
Ejecucin
Ejecucin
Anlisis
Anlisisde
deresultados
resultados

En conclusin
Probar es ejecutar casos de prueba.
Caso de prueba:
entrada + acciones + salida
salida obtenida == salida esperada
salida obtenida != salida esperada

Un programa que pasa todos sus casos de

prueba es un programa sin errores?.

En conclusin

No
Las pruebas slo pueden
encontrar los errores que buscan.
Por esto es tan importante un
buen diseo de pruebas.

Niveles de prueba

Niveles de prueba

10

Niveles de prueba

Pruebas unitarias
Herramientas:
Cuando: Durante la
construccin del sistema.
Objetivo: Prueban el diseo
y el comportamiento de cada
uno de los componentes una
vez construidos.

11

Pruebas unitarias
Tcnicas:
Tcnicas:

Anlisis de caminos.
Particin de categoras.
Mutaciones.
Algoritmos genricos.
Anlisis de valores lmite.
Grficos causa-efecto.
Etc.
En general, han sido muy
estudiadas.

Pruebas de integracin
Herramientas:

Cuando: Durante la construccin

del sistema

Las mismas, vamos sustituyendo los

mocks por las clases reales y, si
es necesario, escribiendo ms
casos de prueba.

Objetivo: Comprueban la correcta

unin de los componentes entre s
a travs de sus interfaces, y si
cumplen con la funcionalidad
establecida.

12

Pruebas de integracin
Tcnicas:
Arriba abajo:
El primer componente que se prueba es el primero
de la jerarqua (A). Una de las ventajas es que las
interfaces entre los distintos componentes se
prueban en una fase temprana y con frecuencia.
Abajo a arriba:
Se prueban primero los componentes de ms bajo
nivel (E, F) Este tipo de enfoque permite un
desarrollo ms en paralelo, pero presenta mayores
dificultades a la hora de planificar y de gestionar.

Pruebas de sistema
Herramientas:

Cuando: Durante la construccin

del sistema (partes completas).
Objetivo: Prueban a fondo el
sistema, comprobando su
funcionalidad e integridad
globalmente, en un entorno lo
ms parecido posible al entorno
final de produccin.

Tcnicas: probar el sistema como

lo har el usuario final.

13

Pruebas de implantacin
Herramientas:

Cuando: Durante la implantacin en

el entrono de produccin.
.
Objetivo: Comprueban el correcto
funcionamiento del sistema dentro del
entorno real de produccin
(rendimiento, copias de seguridad,
etc.).

Las mismas. Las pruebas se vuelven

a ejecutar en el entorno real de
produccin y se aaden nuevas
pruebas.
.

Pruebas de aceptacin
Herramientas:

Cuando: Despus de la
implantacin en el entorno de
produccin.

Las mismas. Las pruebas se vuelven

a ejecutar en el entorno real de
produccin y se aaden nuevas
pruebas.
.

Objetivo: Verifican que el sistema

cumple con todos los requisitos
indicados y permite que los
usuarios del sistema den el visto
bueno definitivo.

14

Pruebas de regresin
Herramientas:
Las mismas.

Cuando: Durante el
mantenimiento del sistema.
Objetivo: Comprobar que los
cambios sobre un componente de
un sistema de informacin, no
introducen un comportamiento no
deseado o errores adicionales en
otros componentes no modificados

4. Pruebas de casos de uso.

15

Introduccin
Un cdigo perfecto no es un sistema software perfecto.
Un ejemplo:

Un sistema software perfecto que

almacena las facturas de un restaurante y
que funciona perfectamente, pero
Si un cliente quiere tomar algo despus de imprimir su
factura, hay que volver a introducir toda la factura.
Si un cliente cambia la forma de pago despus de
imprimir su factura, hay que volver a introducir toda la
factura.

Introduccin
Si el cdigo es perfecto, dnde est el fallo?.

??

Ya lo hemos visto, el sistema debe

satisfacer las necesidades de sus
usuarios.
El sistema debe cumplir sus
requisitos.

16

Prueba del sistema

Pruebas del sistema

17

Pruebas del sistema

PROCESO DE GENERACIN DE PRUEBAS DEL SISTEMA
Requisitos

Modelo de uso

funcionales

Datos de entrada
y resultados esperados

Escenarios.
Diagramas de estados.

Beneficios:
Reduce el tiempo y los recursos necesarios.
Permite sistematizar y automatizar el proceso.
Las pruebas de sistema son independientes de la
plataforma y arquitectura.
Permite validar de forma temprana los requisitos,
permitiendo corregir las deficiencias que presenten.

Tcnicas
En resumen:

Probar un caso de uso es definir un

conjunto de escenarios y ejecutarlos
sobre el sistema para comprobar si el
resultado coincide con la definicin
del caso de uso.

18

5. Automatizacin de las pruebas

Automatizacin de las pruebas

Algunas palabras que hemos escuchado hablando de pruebas.

No sirven para nada

Prdida de tiempo
Imposibles de mantener

Engao
Descartadas al primer cambio
Moda pasajera

Por qu?.

19

Automatizacin de las pruebas

Las pruebas son polmicas:
No son parte de la solucin.
No se las entregamos a nuestros clientes.
Incluso pueden darles a nuestros clientes una
mala impresin.
Nuestros clientes no nos las pagan.
Difciles de mantener.

Sin embargo, las pruebas son imprescindibles.

?

Automatizar.

Qu hacer?.

Automatizacin de las pruebas

Qu significa automatizar?.
En este caso concreto: realizar de manera
automtica mediante herramientas
software.

Qu podemos automatizar?.
Diseo de las pruebas

Menos habitual, pocas tcnicas y

herramientas.

Codificacin de las pruebas

El objetivo de esta presentacin

Ejecucin de las pruebas

Evaluacin de resultados

Lo ms habitual, muchas tcnicas y

herramientas

20

Automatizacin de las pruebas

Ventajas:

Mayor rapidez de
ejecucin.
Menos recursos.
Evitamos pruebas
obsoletas

Inconvenientes:

Muy pocas
herramientas!.
Necesitan una base a
menudo inexistente.
Un conjunto pobre de
pruebas.

Automatizacin de las pruebas

Cuando automatizar y cuando no automatizar.
Bien

Mal.

No buscamos
automatizarlo
absolutamente todo.

Gastamos ms en la
automatizacin que en
la pruebas en s.

Tenemos modelos y
documentacin del
sistema.

Construimos el sistema
sobre la marcha.

Nosotros controlamos
las herramientas de
prueba.

Las herramientas de
prueba nos controlan a
nosotros.

21

Conclusiones
Las
Las herramientas
herramientas son
son importantes
importantes pero
pero
Una
Una herramienta
herramienta de
de prueba
prueba no
noes
esuna
una
estrategia
ni
un
proceso
ni
un
plan
estrategia ni un proceso ni un plande
deprueba.
prueba.
Una
Unaherramienta
herramientade
depruebas
pruebassin
sinsaber
sabertcnicas,
tcnicas,prcticas
prcticas
yytener
tenerexperiencia
experienciaen
enpruebas
pruebases
estan
tantil
tilcomo
comoun
un
entorno
entornode
deprogramacin
programacinsin
sinsaber
saberelellenguaje.
lenguaje.

Es necesario tener conocimientos !!!

Fin
Qu
Qu vamos
vamos aa ver
ver aa partir
partir de
de aqu?
aqu?
1:
1: Cmo
Cmo definir
definir casos
casosde
deuso
usoyyotros
otrosrequisitos
requisitos
para
para que
que se
se puedan
puedan probar.
probar.
2:
2: Algunas
Algunas propuestas
propuestas existentes
existentespara
paraextraer
extraer
pruebas
a
partir
de
casos
de
uso.
pruebas a partir de casos de uso.
3:
3:El
Elproceso
procesoETUC
ETUCyyun
uncaso
casoprctico.
prctico.

22