Laura Patricia Pinto Prieto
Introducción




Las pruebas del software son un elemento crítico para la
garantía de calidad del software y representa una revisión
final de las especificaciones, del diseño y de la codificación.
La creciente percepción del software como un elemento del
sistema y la importancia de los «costes» asociados a un fallo
del propio sistema, están motivando la creación de pruebas
minuciosas y bien planificadas.
No es raro que una organización 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 críticas (por ejemplo, control de tráfico
aéreo, control de reactores nucleares) puede costar de tres a
cinco veces más que el resto de los pasos de la ingeniería del
software juntos!
¿Qué es probar software?
Algunas definiciones incorrectas:
• Probar es demostrar que no hay errores
presentes en un programa.
• El propósito de probar es mostrar que el programa
realiza correctamente las funciones esperadas.
La definición Correcta
• Probar es el proceso ejecución 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, diseñados para
comprobar la lógica interna y los
requisitos externos. Se determinan los
resultados esperados y se guardan los
resultados realmente obtenidos.
Relación entre error, defecto y fallo
Objetivos de la Prueba.
La prueba es el proceso de ejecución de
un programa con la intención 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 dramático de
punto de vista. Nos quitan la idea que, normalmente, tenemos
de que una prueba tiene éxito si no descubre errores.

Nuestro objetivo es diseñar pruebas que sistemáticamente
saquen a la luz diferentes clases de errores, haciéndolo 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 debería poder
hacer un seguimiento hasta los requisitos
del cliente.
 Las pruebas deberían planificarse mucho
antes de que empiecen. La planificación de
las pruebas pueden empezar tan pronto
como esté completo el modelo de
requisitos.
 Las pruebas deberían empezar por “lo
pequeño” 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 lógica del
programa y asegurarse de que se han aplicado todas
las condiciones en el diseño a nivel de componente.

Para ser más eficaces (pruebas con la más alta
probabilidad de encontrar errores), las pruebas
deberían 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 síntomas 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 válidos y esperados
como no válidos 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, prácticamente, 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 difícil, merece la
pena saber qué se puede hacer para hacerlo más
sencillo. A veces los programadores están dispuestos
a hacer cosas que faciliten el proceso de prueba y una
lista de comprobación de posibles puntos de diseño,
características, etc., puede ser útil a la hora de negociar
con ellos.
 La siguiente lista de comprobación proporciona un
conjunto de características que llevan a un software fácil
de probar.

Operatividad.
«Cuanto mejor funcione, más eficientemente
se puede probar.»
El sistema tiene pocos errores (los errores
añaden sobrecarga de análisis y de
generación de informes al proceso de
prueba).
Ningún error bloquea la ejecución 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 están visibles o se
pueden consultar durante la ejecución.
 Los estados y variables anteriores del sistema están
visibles o se pueden consultar (por ejemplo, registros de
transacción).
 Todos los factores que afectan a los resultados están
visibles.
 Un resultado incorrecto se identifica fácilmente.
 Los errores internos se detectan automáticamente a
través de mecanismos de auto-comprobación.
 Se informa automáticamente de los errores internos.
 El código fuente es accesible.
Controlabilidad
«Cuanto mejor podamos controlar el software, más se
puede automatizar y optimizar.»
 Todos los resultados posibles se pueden generar a
través de alguna combinación de entrada.
 Todo el código es ejecutable a través de alguna
combinación 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 descomposición.
«Controlando el ámbito de las pruebas,
podemos aislar más rápidamente los
problemas y llevar a cabo mejores
pruebas de regresión.»
 El sistema software está construido con
módulos independientes.
 Los módulos del software se pueden
probar independientemente
Simplicidad.
«Cuanto menos haya que probar, más
rápidamente podremos probarlo.»
 Simplicidad funcional (por ejemplo, el
conjunto de características es el mínimo
necesario para cumplir los requisitos).
 Simplicidad estructural (por ejemplo, la
arquitectura es modularizada para limitar la
propagación de fallos).
 Simplicidad del código (por ejemplo, se
adopta un estándar de código para facilitar
la inspección y el mantenimiento).
Estabilidad.
«Cuanto menos cambios, menos
interrupciones a las pruebas.»
 Los cambios del software son
infrecuentes.
 Los cambios del software están
controlados.
 Los cambios del software no invalidan las
pruebas existentes.
 El software se recupera bien de los fallos.
Facilidad de comprensión.








«Cuanta más información tengamos, más
inteligentes serán las pruebas.»
El diseño se ha entendido perfectamente.
Las dependencias entre los componentes internos,
externos y compartidos se han entendido
perfectamente.
Se han comunicado los cambios del diseño.
La documentación técnica es instantáneamente
accesible.
La documentación técnica está bien organizada.
La documentación técnica es específica y detallada.
La documentación técnica 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 depuración (localización y corrección
de defectos).

El análisis de la estadística de errores.
Ciclo completo de las Pruebas
Diseño de casos de prueba
1.
2.
Prueba de caja negra :Conociendo la función
específica para la que fue diseñado el
producto, se pueden llevar a cabo pruebas
que demuestren que cada función es
completamente operativa y, al mismo, tiempo
buscando errores en cada función;
Prueba de caja blanca : Conociendo el
funcionamiento del producto, se pueden
desarrollar pruebas que aseguren que «todas
las piezas encajan», o sea, que la operación
interna se ajusta a las especificaciones y que
todos los componentes internos se han
comprobado de forma adecuada.
Diseño de casos de prueba.
Enfoques principales
(Piattini et al. 96)
Pruebas de Software
26
Profesor:
Juan Antonio
López
Quesada
Diseño de casos de prueba.
Comparación 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 consistiría en probar todos los
posibles caminos de ejecución
 nº caminos lógicos  ( buscar los más importantes)
b) Enfoque funcional o de caja negra:
 para derivar los casos, se estudia la especificación de
las funciones, la entrada y la salida.

No son excluyentes.
Pruebas de Software
27
Profesor:
Juan Antonio
López
Quesada
Prueba de caja blanca
¿Porqué usar pruebas de caja blanca?
 Los errores lógicos y las suposiciones
incorrectas son inversamente proporcionales a
la probabilidad de que se ejecute un camino del
programa.
 A veces creemos que un camino lógico tiene
pocas posibilidades de ejecutarse cuando
puede hacerlo de forma normal.
“Los errores se esconden en los rincones y se
aglomeran en los límites” (Beizer 90)
Pruebas de Software
28
Profesor:
Juan Antonio
López
Quesada
Prueba del camino básico
(Mc Cabe 76)
Objetivos:
1. Obtener una medida de la complejidad lógica


de un diseño procedimental
 Complejidad ciclomática de Mc Cabe
2. Usar esa medida como guía para la definición
de un conjunto básico de caminos de
ejecución
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.
29
Grafo de Flujo de las Estructuras Básicas de
programa
X
X
X
Secuencia
Si x Entonces…
(If x Then … Else…)
Hacer … hasta x
(Do … Until x)
Repetir
Mientras x Hacer …
(While x Do … )
Separar todas las condiciones
 Agrupar sentencias ‘simples’ en bloques
 Numerar todos los bloques y tambien las
condiciones

Grafo de flujo
Cada círculo, denominado nodo
del grafo de flujo, representa una o más sentencias
procedimentales.
Un solo nodo puede corresponder a una
secuencia de cuadros de proceso y a un rombo de
decisión.
Las flechas del grafo de flujo, denominadas aristas
o enlaces, representan flujo de control y son
análogas 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, véase el símbolo para la construcción
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 región más.
Prueba del camino Básico

Complejidad Ciclomatica(La complejidad
de McCabe V (G))
 La métrica de McCabe ha sido muy popular en
el diseño de pruebas.
 Define el número de caminos independientes
del conjunto básico de un programa y nos da un
límite superior para el número de pruebas que
se deben realizar para asegurar que se ejecuta
cada sentencia al menos una vez.
¿Cómo sabemos cuántos
caminos hemos de buscar?
El cálculo de la complejidad ciclomática nos da la respuesta.
La complejidad se puede calcular de
tres formas:
1. El número de regiones del grafo de flujo coincide.
2. La complejidad ciclomática, V(G), de un grafo de
con la complejidad ciclomática. flujo G se define como.
donde A es el número de aristas del grafo de flujo y N es
el número de nodos del mismo.
3. La complejidad ciclomática, V(G), de un grafo de
flujo G también se define como
V(G)=P+ 1 donde P es el número de nodos predicado
contenidos en el grafo de flujo G.
Formas de Calcular la Complejidad
Ciclomática 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 condición.
¿Qué es lo que se logra con la
complejidad ciclomática?

V(G) marca el límite mínimo de casos
de prueba para un programa.

Cuando V (G) >10 la probabilidad de
defectos en el módulo o programa crece
mucho entonces quizás sea interesante
dividir el módulo.
Ejemplo de calculo de V (G)
1
a1
a2
a4
a8
5
a9
Región 3
a10
a11
7
a13
6
10
Región 5
11

c) V (G) = 4+1= 5
Condiciones
a12
Región 4
9
b) V (G) = 5 Regiones
Cerradas.
a7
4
Región 2

Región 1
a5
a6
a) V (G) =14-11+2=5
a3
2
3

a14
8
Es más, el valor de V(G) nos da un límite superior
para el número de caminos independientes que
componen el conjunto básico y,
consecuentemente, un valor límite superior para
el número de pruebas que se deben diseñar y
ejecutar para garantizar que se cubren todas las
sentencias del programa.
Trabajo para entregar la próxima clase
(nota 40% segundo corte en grupo de a 3
personas máximo)
1. Ejercicio:
a.
b.
2.
3.
Myers [MYE79] usa el siguiente programa como
autocomprobación de su capacidad para
especificar una prueba adecuada: un programa
lee tres valores enteros. Los tres valores se
interpretan como representación de la longitud de
los tres lados de un triángulo. El programa imprime
un mensaje indicando si el triángulo es escaleno,
isósceles o equilátero.
Desarrolle el programa y haga el grafo de flujo
,calcule V(G) y obtenga los casos de prueba. (ver
ejemplo del libro de pressman).
Investigar sobre Matriz de grafos.
Pruebas de estructuras de control
Próxima Clase

Parcial sobre Diseño de componentes,
pruebas de software, hasta pruebas de
caja blanca, incluyendo los puntos del
trabajo de investigación.
En el libro de Pressman 5 ed. son
capítulos:
16- Diseño a nivel de componentes.
17- Técnicas de prueba de software.

BIBLIOGRAFIA

Fairley R. Ingeniería de Software.

Pressman, R.S. Ingeniería del Software. Un enfoque
práctico.

Presentación de Juan Antonio López Quesada.
Facultado de Informática.
Descargar

Pruebas del software parte 1 laura Pinto