Laura Patricia Pinto Prieto

Introduccin
Las pruebas del software son un elemento crtico para la
garanta de calidad del software y representa una revisin
final de las especificaciones, del diseo y de la codificacin.
La creciente percepcin del software como un elemento del
sistema y la importancia de los costes asociados a un fallo
del propio sistema, estn motivando la creacin de pruebas
minuciosas y bien planificadas.
No es raro que una organizacin de desarrollo de software
emplee
entre el 30 y el 40 por ciento del esfuerzo total de un proyecto
en las pruebas. En casos extremos,las pruebas del software
para actividades crticas (por ejemplo, control de trfico
areo, control de reactores nucleares) puede costar de tres a
cinco veces ms que el resto de los pasos de la ingeniera del
software juntos!

Qu es probar software?

Algunas definiciones incorrectas:
Probar es demostrar que no hay errores
presentes en un programa.
El propsito de probar es mostrar que el programa
realiza correctamente las funciones esperadas.
La definicin Correcta
Probar es el proceso ejecucin de un programa
con el fin de encontrar errores.

Otras Definiciones
Verificar.
Validar.
Pruebas.
Caso de Prueba.
Defecto.
Fallo.
Error.
Producto obtenido
Se define y documenta un conjunto de
casos de prueba, diseados para
comprobar la lgica interna y los
requisitos externos. Se determinan los
resultados esperados y se guardan los
resultados realmente obtenidos.
Relacin entre error, defecto y fallo
Objetivos de la Prueba.
La prueba es el proceso de ejecucin de
un programa con la intencin de
descubrir un error.
Un buen caso de prueba es aquel que
tiene una alta probabilidad de mostrar
un error no descubierto hasta entonces.
Una prueba tiene xito si descubre un
error no detectado hasta entonces.
Principal objetivo
Los objetivos anteriores suponen un cambio dramtico de
punto de vista. Nos quitan la idea que, normalmente, tenemos
de que una prueba tiene xito si no descubre errores.

Nuestro objetivo es disear pruebas que sistemticamente
saquen a la luz diferentes clases de errores, hacindolo con la
menor cantidad de tiempo y de esfuerzo.

Si la prueba se lleva a cabo con xito (de acuerdo con el objetivo
anteriormente establecido), descubrir errores en el software.

Como ventaja secundaria, la prueba demuestra hasta qu punto
las funciones del software parecen funcionar de acuerdo con las
especificaciones y parecen alcanzarse los requisitos de
rendimiento.
Principios de las pruebas
A todas las pruebas se les debera poder
hacer un seguimiento hasta los requisitos
del cliente.
Las pruebas deberan planificarse mucho
antes de que empiecen. La planificacin de
las pruebas pueden empezar tan pronto
como est completo el modelo de
requisitos.
Las pruebas deberan empezar por lo
pequeo y progresar hacia lo grande.
Principios de las pruebas
No son posibles las pruebas exhaustivas: es
imposible ejecutar todas las combinaciones de
caminos durante las pruebas. Es posible, sin
embargo, cubrir adecuadamente la lgica del
programa y asegurarse de que se han aplicado todas
las condiciones en el diseo a nivel de componente.

Para ser ms eficaces (pruebas con la ms alta
probabilidad de encontrar errores), las pruebas
deberan ser realizadas por un equipo independiente.


Principios de las pruebas
Se debe inspeccionar a conciencia el
resultado de cada prueba para, as, poder
descubrir posibles sntomas de defectos.
Cada caso de prueba debe definir el resultado
de salida esperado.
Al generar casos de prueba, se deben incluir
tanto datos de entrada vlidos y esperados
como no vlidos e inesperados.
Principios de las pruebas

Las pruebas deben centrarse en dos
objetivos (es habitual olvidar el
segundo)
Probar si el software no hace lo que debe
hacer
Probar si el software hace lo que no debe
hacer, es decir si provoca efectos
secundarios
Se deben evitar los casos desechables.

Principios de las pruebas
No deben hacerse planes de prueba
suponiendo que, prcticamente, no hay
defectos en los programas, y dedicando
pocos recursos a las pruebas.
La experiencia indica que donde hay un
defecto hay otros.
Las pruebas son una tarea creativa
como el desarrollo de software.
Facilidad de Prueba
James Bach describe la facilidad de prueba de la siguiente
manera:

La facilidad de prueba del software es simplemente la
facilidad con la que se puede probar un programa de
computadora.
Como la prueba es tan profundamente difcil, merece la
pena saber qu se puede hacer para hacerlo ms
sencillo. A veces los programadores estn dispuestos
a hacer cosas que faciliten el proceso de prueba y una
lista de comprobacin de posibles puntos de diseo,
caractersticas, etc., puede ser til a la hora de negociar
con ellos.
La siguiente lista de comprobacin proporciona un
conjunto de caractersticas que llevan a un software fcil
de probar.
Operatividad.
Cuanto mejor funcione, ms eficientemente
se puede probar.
El sistema tiene pocos errores (los errores
aaden sobrecarga de anlisis y de
generacin de informes al proceso de
prueba).
Ningn error bloquea la ejecucin de las pruebas
El producto evoluciona en fases funcionales
(permite simultanear el desarrollo y las
pruebas).
Observabilidad.
Lo que ves es lo que pruebas.
Se genera una salida distinta para cada entrada.
Los estados y variables del sistema estn visibles o se
pueden consultar durante la ejecucin.
Los estados y variables anteriores del sistema estn
visibles o se pueden consultar (por ejemplo, registros de
transaccin).
Todos los factores que afectan a los resultados estn
visibles.
Un resultado incorrecto se identifica fcilmente.
Los errores internos se detectan automticamente a
travs de mecanismos de auto-comprobacin.
Se informa automticamente de los errores internos.
El cdigo fuente es accesible.
Controlabilidad
Cuanto mejor podamos controlar el software, ms se
puede automatizar y optimizar.
Todos los resultados posibles se pueden generar a
travs de alguna combinacin de entrada.
Todo el cdigo es ejecutable a travs de alguna
combinacin de entrada.
El ingeniero de pruebas puede controlar directamente
Los estados y las variables del hardware y del software.
Los formatos de las entradas y los resultados son
consistentes y estructurados.
Las pruebas pueden especificarse, automatizarse y
reproducirse convenientemente.
Capacidad de
descomposicin.
Controlando el mbito de las pruebas,
podemos aislar ms rpidamente los
problemas y llevar a cabo mejores
pruebas de regresin.
El sistema software est construido con
mdulos independientes.
Los mdulos del software se pueden
probar independientemente
Simplicidad.
Cuanto menos haya que probar, ms
rpidamente podremos probarlo.
Simplicidad funcional (por ejemplo, el
conjunto de caractersticas es el mnimo
necesario para cumplir los requisitos).
Simplicidad estructural (por ejemplo, la
arquitectura es modularizada para limitar la
propagacin de fallos).
Simplicidad del cdigo (por ejemplo, se
adopta un estndar de cdigo para facilitar
la inspeccin y el mantenimiento).
Estabilidad.
Cuanto menos cambios, menos
interrupciones a las pruebas.
Los cambios del software son infrecuentes.
Los cambios del software estn
controlados.
Los cambios del software no invalidan las
pruebas existentes.
El software se recupera bien de los fallos.
Facilidad de comprensin.
Cuanta ms informacin tengamos, ms
inteligentes sern las pruebas.
El diseo se ha entendido perfectamente.
Las dependencias entre los componentes internos,
externos y compartidos se han entendido
perfectamente.
Se han comunicado los cambios del diseo.
La documentacin tcnica es instantneamente
accesible.
La documentacin tcnica est bien organizada.
La documentacin tcnica es especfica y detallada.
La documentacin tcnica es exacta.
Bondad de una Prueba

Debe tener una alta probabilidad de
encontrar un error.
No debe ser redundante.
Debe ser la mejor de todas las posibles.
No debe ser ni demasiado sencilla ni
demasiado compleja.
El proceso de Prueba

La depuracin (localizacin y correccin
de defectos).

El anlisis de la estadstica de errores.
Ciclo completo de las Pruebas
Diseo de casos de prueba
1. Prueba de caja negra :Conociendo la funcin
especfica para la que fue diseado el
producto, se pueden llevar a cabo pruebas
que demuestren que cada funcin es
completamente operativa y, al mismo, tiempo
buscando errores en cada funcin;
2. Prueba de caja blanca : Conociendo el
funcionamiento del producto, se pueden
desarrollar pruebas que aseguren que todas
las piezas encajan, o sea, que la operacin
interna se ajusta a las especificaciones y que
todos los componentes internos se han
comprobado de forma adecuada.
Pruebas de Software 26
Profesor:
Juan Antonio
Lpez
Quesada
Diseo de casos de prueba.
Enfoques principales
(Piattini et al. 96)

Pruebas de Software 27
Profesor:
Juan Antonio
Lpez
Quesada
Diseo de casos de prueba.
Comparacin de los Enfoques
principales
a) Enfoque estructural o de caja blanca
(transparente):
se centra en la estructura interna del programa para
elegir los casos de prueba
la prueba exhaustiva consistira en probar todos los
posibles caminos de ejecucin
n caminos lgicos ( buscar los ms importantes)
b) Enfoque funcional o de caja negra:
para derivar los casos, se estudia la especificacin de
las funciones, la entrada y la salida.
No son excluyentes.
Pruebas de Software 28
Profesor:
Juan Antonio
Lpez
Quesada
Prueba de caja blanca
Porqu usar pruebas de caja blanca?
Los errores lgicos y las suposiciones
incorrectas son inversamente proporcionales a
la probabilidad de que se ejecute un camino del
programa.
A veces creemos que un camino lgico tiene
pocas posibilidades de ejecutarse cuando
puede hacerlo de forma normal.
Los errores se esconden en los rincones y se
aglomeran en los lmites (Beizer 90)
29
Prueba del camino bsico
(Mc Cabe 76)
Objetivos:
1. Obtener una medida de la complejidad lgica
de un diseo procedimental
Complejidad ciclomtica de Mc Cabe
2. Usar esa medida como gua para la definicin
de un conjunto bsico de caminos de
ejecucin
Los casos de prueba obtenidos garantizan que
durante la prueba se ejecuta al menos una vez
cada sentencia del programa (cobertura de
sentencias).
Se puede automatizar.
Grafo de Flujo de las Estructuras Bsicas de
programa
Separar todas las condiciones
Agrupar sentencias simples en bloques
Numerar todos los bloques y tambien las
condiciones


X
X
X
Secuencia
Si x Entonces
(If x Then Else)
Hacer hasta x
(Do Until x)
Repetir

Mientras x Hacer
(While x Do )
Grafo de flujo
Cada crculo, denominado nodo
del grafo de flujo, representa una o ms sentencias
procedimentales.
Un solo nodo puede corresponder a una
secuencia de cuadros de proceso y a un rombo de
decisin.
Las flechas del grafo de flujo, denominadas aristas
o enlaces, representan flujo de control y son
anlogas a las flechas del diagrama de flujo. Una arista
debe terminar en un nodo, incluso aunque el nodo
no represente ninguna sentencia procedimental (por
ejemplo, vase el smbolo para la construccin
Si-entonces-si-no). Las reas delimitadas por aristas
y nodos se denominan regiones. Cuando
contabilizamos las regiones incluimos el rea exterior del
grafo, contando como otra regin ms.
Prueba del camino Bsico
Complejidad Ciclomatica(La complejidad
de McCabe V (G))

La mtrica de McCabe ha sido muy popular en
el diseo de pruebas.

Define el nmero de caminos independientes
del conjunto bsico de un programa y nos da un
lmite superior para el nmero de pruebas que
se deben realizar para asegurar que se ejecuta
cada sentencia al menos una vez.
Cmo sabemos cuntos
caminos hemos de buscar?

El clculo de la complejidad ciclomtica nos da la respuesta.
La complejidad se puede calcular de
tres formas:
1. El nmero de regiones del grafo de flujo coincide.

2. La complejidad ciclomtica, V(G), de un grafo de
con la complejidad ciclomtica. flujo G se define como.
donde A es el nmero de aristas del grafo de flujo y N es
el nmero de nodos del mismo.

3. La complejidad ciclomtica, V(G), de un grafo de
flujo G tambin se define como
V(G)=P+ 1 donde P es el nmero de nodos predicado
contenidos en el grafo de flujo G.
Formas de Calcular la Complejidad
Ciclomtica V(G)
V (G) = a n + 2
V (G) = r
V (G) = c + 1
Donde
a : # de arcos o aristas del grafo.
n : # de nodos.
r : # de regiones cerradas del grafo.
c : # de nodos de condicin.

Qu es lo que se logra con la
complejidad ciclomtica?

V(G) marca el lmite mnimo de casos
de prueba para un programa.

Cuando V (G) >10 la probabilidad de
defectos en el mdulo o programa crece
mucho entonces quizs sea interesante
dividir el mdulo.
Ejemplo de calculo de V (G)




a) V (G) =14-11+2=5

b) V (G) = 5 Regiones
Cerradas.

c) V (G) = 4+1= 5
Condiciones


Es ms, el valor de V(G) nos da un lmite superior
para el nmero de caminos independientes que
componen el conjunto bsico y,
consecuentemente, un valor lmite superior para
el nmero de pruebas que se deben disear y
ejecutar para garantizar que se cubren todas las
sentencias del programa.

1
2
3
4
5
6
7 8
9
10
11
a1
a2 a3
a4
a5
a6 a7
a8
a9
a10
a11 a12
a13 a14
Regin 1
Regin 2
Regin 3
Regin 4
Regin 5
Trabajo para entregar la prxima clase
(nota 40% segundo corte en grupo de a
3 personas mximo)
1. Ejercicio:
a. Myers [MYE79] usa el siguiente programa como
autocomprobacin de su capacidad para
especificar una prueba adecuada: un programa
lee tres valores enteros. Los tres valores se
interpretan como representacin de la longitud de
los tres lados de un tringulo. El programa imprime
un mensaje indicando si el tringulo es escaleno,
issceles o equiltero.
b. Desarrolle el programa y haga el grafo de flujo
,calcule V(G) y obtenga los casos de prueba. (ver
ejemplo del libro de pressman).
2. Investigar sobre Matriz de grafos.
3. Pruebas de estructuras de control

Prxima Clase
Parcial sobre Diseo de componentes,
pruebas de software, hasta pruebas de
caja blanca, incluyendo los puntos del
trabajo de investigacin.

En el libro de Pressman 5 ed. son
captulos:
16- Diseo a nivel de componentes.
17- Tcnicas de prueba de software.


BIBLIOGRAFIA
Fairley R. Ingeniera de Software.

Pressman, R.S. Ingeniera del Software. Un enfoque
prctico.

Presentacin de Juan Antonio Lpez Quesada.
Facultado de Informtica.