Está en la página 1de 41

PRUEBA DE SOFTWARE

n El desarrollo de software implica


actividades en que es posible
que aparezca el fallo humano.
n

n Debido a la imposibilidad humana


de trabajar y comunicarse de
forma perfecta, el Diseño debe ir
acompañado de una actividad
que garantice la CALIDAD.
n Una vez generado el código, el
Software debe ser probado para
descubrir y corregir el máximo de
errores posibles antes de su
entrega. Se debe recordar que
cada vez que el cliente ejecuta el
programa, éste se está
probando.

n Por tanto, se debe diseñar una


serie de casos de prueba que
tengan una alta probabilidad de
encontrar errores en el software
antes de entregarlo al cliente.
n Estas técnicas de prueba de software
permiten diseñar pruebas que:

1. Comprueben la lógica interna de los


componentes de software.

1. Verifiquen los dominios de Entrada –


Salida para descubrir errores en la
funcionalidad, comportamiento y
rendimiento del software.
n De tal modo el software se prueba
desde 2 perspectivas:
n

1. La lógica interna se comprueba


utilizando Técnicas de “Caja
Blanca”.

2. Los requisitos del software se


comprueban utilizando Técnicas de
“Caja Negra”.
I. - FUNDAMENTOS DE LAS
PRUEBAS DE SOFTWARE.
n FASES:

Definición
 Desarrollo
Pruebas
Construir software partiendo Serie de Casos que
de un concepto abstracto y intentaran “Demoler”
llegando a una el software construido.
implementación tangible.
a) OBJETIVOS DE LAS PRUEBAS.
1.Probar es ejecutar un programa con el
objeto de descubrir un error.
2.Un buen caso de prueba tiene una alta
probabilidad de mostrar un error
NO descubierto.
3.Una prueba tiene éxito si descubre un
error NO detectado hasta
entonces.
4.
 Por lo tanto se deben diseñar pruebas

que saquen a la luz diferentes clases


de errores, con la menor cantidad de
tiempo y esfuerzo posible.
Ventajas de las Pruebas de
Software.
1.Descubrirán errores en el software
2.Demostrarán hasta que punto las
funciones del software parecen
funcionar de acuerdo con las
especificaciones y parecen alcanzar
los requisitos de rendimiento.
3.Los datos que se recolectan con ellas
proporcionan la indicación de
a) Fiabilidad del Software.
b) Calidad del Software como un todo.
b) Principios de las Pruebas.
Las pruebas de Software deberían:

1.Hacer un seguimiento hasta los


requisitos del cliente.
2.
3.Planificarse mucho antes de que
empiecen, o, se pueden planificar
y diseñar aún antes de generar
código.
Principios de las Pruebas.
3.Aplicar Principio de Pareto:
80% de errores descubiertos
se les puede hacer un
seguimiento hasta 20% de
todos los módulos del
programa.
4.Empezar por “lo pequeño” y
progresar hacia “lo
grande”.
Principios de las Pruebas.
5.
 No realizar pruebas
exhaustivas, solo cubrir
adecuadamente la lógica del
programa.
n

6.Ser realizadas por equipo


independiente.
c) Facilidad de Prueba.
Es la facilidad con que se puede

probar un programa de
computadora.
Caract eríst icas de Soft ware fácil de probar:
•El sist em a t iene pocos
1)Operatividad errores
Cuanto mejor funcione
•Ningún error bloquea la
más eficiente se puede
probar ejecución de las
pruebas.
•El product o evoluciona
de t al form a que
perm it e
sim ult áneam ent e el
•Se genera una salida dist int a
para cada ent rada.
2) Observabilidad •Est ados y Variables del sist em a
Lo que ves es lo que est án visibles y se pueden
pruebas consult ar.
•Todos los fact ores que afect an a
los result ados est án visibles
•Un result ado incorrect o se
ident ifica fácilm ent e
•Los errores int ernos se det ect an
aut om át icam ent e a t ravés de
m ecanism os de
aut ocom probación.
•Se inform a aut om át icam ent e de
los errores int ernos.
•Código Fuent e es accesible.
•Todos los resultados posibles
son producto de alguna
3) Controlabilidad combinación de entrada
Cuanto más se
pueda controlar el •Todo el código es ejecutable a
través de alguna
sw, más se puede
combinación de entrada
automatizar y
optimizar •Se pueden controlar
directamente los estados y
variables del hw y sw
•Formatos de entradas y
resultados son consistentes
y estructurados.
•Pruebas pueden especificarse,
automatizarse y
reproducirse.
4) Capacidad de •Software construido con
Descomposición módulos independientes.
Controlando el ámbito
de las pruebas, se •Módulos pueden probarse
puede aislar independientemente.
rápidamente los
problemas.
•Funcional. Incluir solamente
el mínimo de
5) Simplicidad características necesarias
Cuanto menos hay para cumplir el requisito
que probar, más
rápido se realiza •Estructurada. Ejemplo, la
estructura modularizada.
•Del Código. Estandarización
de código.
•Cambios de SW son Infrecuentes
6) Estabilidad •Cambios Controlados
Cuanto menos cambios •Cambios del SW no invalidan
menos interrupciones a Pruebas anteriores.
las pruebas •El sw se recupera de los fallos

•Diseño se ha entendido
perfectamente.
7)Facilidad de
•Se comprenden las dependencias
Comprensión entre componente internos,
externos y compartidos
Cuanta más
información se cuente, •Documentación técnica es:
más inteligente serán Accesible, Bien organizada,
las pruebas Detallada y Exacta
Características de una “Buena
Prueba”
Una buena prueba se dice que:

1.Tiene alta probabilidad de encontrar


un error.
2.No debe ser redundante.
3.Debería ser la “mejor de la cosecha”
4.No debe ser ni demasiado sencilla ni
demasiado compleja.
II. – DISEÑO DE CASOS
DE PRUEBA.
A nivel general, una prueba:

n De Caja Negra, es para conocer la

función específica para la que fue


diseñado el software, realizar
pruebas que demuestren que cada
función es operativa y al mismo
tiempo, buscando errores en cada
función.
n Una prueba de Caja Blanca, es
para conocer el funcionamiento
del producto y asegurar que
“todas las piezas encajan”, la
operación interna se ajusta a lo
especificado y que todos los
componentes internos se han
comprobado en forma adecuada.
A nivel de Software:
 Caja Negra  Caja Blanca
n Pruebas que se n Minucioso
llevan a nivel de examen de
interfaz. detalles
n Si las funciones son procedimentale
operativas. s.
n Si entradas se n Comprobar
aceptan de forma caminos
adecuada y con
resultado lógicos.
correcto. n Examinar estado
n Si Mantiene del programa
integridad de la para determinar
información si el estado real
externa. coincide con el
1) PRUEBA DE CAJA
BLANCA.
Usa la estructura de control del

diseño procedimental para


obtener los casos de prueba que:
1.Garanticen que se ejercita por lo
menos una vez todos los
caminos independientes de
cada módulo.
2.Ejerciten todas las decisiones
lógicas.
3.Ejecuten todos los bucles en sus
límites.
4.Ejerciten Estructuras Internas de
¿Por qué es necesario probar la lógica en
vez de asegurar alcanzar los requisitos del
programa?
Porque:
1. Errores lógicos y suposiciones incorrectas son
inversamente proporcionales a la probabilidad
de que se ejecute un camino del programa.
2. El Flujo lógico del programa a veces no es intuitivo,
los errores de diseño solo se descubren cuando
comienza la prueba del camino.
3. Los errores tipográficos son aleatorios, estos
errores de escritura serán:
 a) Descubiertos por la comprobación de
sintaxis del lenguaje.
 b) Permanecerán ocultos hasta que comience
la prueba.
1.
1.1) PRUEBA DEL CAMINO
BASICO.
n Técnica de prueba de caja blanca.
n
n Obtiene una medida de la
complejidad lógica de un diseño
procedimental.
n
n Usa esa medida como guía para la
definición de un conjunto básico
de caminos de ejecución.
Notación de Grafo de Flujo.
n Representa el flujo de control
lógico mediante la notación:
Repet ir
Secuenci hast a
a que

Si_Si_No
(If)

Según
Sea
(Case)
Mient ras
(While)
1
2

6 4

7 8 5
9
1
1 10
1
1 Aristas
Nodos
2

3 2,
3
6 4
4,
6 5
R2
7 8 5
7 R3 8
9 1 R1
1
1 0
•Cada nodo representa una o más
sentencias procedimentales. 9 1 R4
•Un nodo puede representar un cuadro 0
de proceso y un rombo de decisión.
•Nodo predicado – dos o más aristas 1
emergen de éste.
1 Región
Complejidad Ciclomática
n Es una métrica del software que
proporciona una medición cuantitativa
de la complejidad lógica de un
programa.
n
n En el contexto del método de prueba
del camino básico, 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.
Camino Independiente.
n Camino de programa que
introduce por lo menos un nuevo
conjunto de sentencias o una
condición.
n

n En el grafo está constituido por lo


menos por una arista que no
haya sido recorrida antes.
¿Cuántos caminos
n El cálculoBuscar?
de la complejidad
ciclomática nos da el número de
caminos. Este se puede calcular
de 3 formas:
1. Número de Regiones Coincide con
la complejidad ciclomática. = R
2. V(G) = A - N + 2
3. V(G) = P + 1
En donde
N: Numero de Nodos; A: Número de
Aristas
P: Número de Nodos Predicado
1
COMPLEJIDAD CICLOMÁTICA
Arist as
Nodos
V(G) = A - N + 2
1.

2
, 1. V(G) = 11 – 9 + 2 = 4
3 4
6 , 2. V(G) = P + 1
R2 5
7 R3 8 R1

9 1 R4
0

1
1 Región
1 •Camino 1: 1-11

2 •Camino 2:1-2-3-4-5-10-1-11
, •Camino 3:1-2-3-6-8-9-10-1-11
3 4
6 , •Camino 4:1-2-3-6-7-9-10-1-11
5
7 •NO Camino Independiente: 1-2-3-
8 4-5-10-1-2-3-6-8-9-10-1-11
9 1
0
1 Conjunto Básico de Caminos:
1
Si una prueba fuerza la ejecución de esos
caminos, se garantizará que se habrá
ejecutado al menos una vez cada
sentencia
•El método se puede aplicar al diseño procedimental
detallado y directamente al código fuente.

PASOS DEL METODO DEL


CAMINO BASICO.
1.Usando el Diseño o el Código,
dibujar el grafo.
2.Determinar la complejidad
ciclomática.
3.Determinar el Conjunto básico de
Caminos Independientes.
4.Preparar casos de prueba que
forzarán la ejecución de cada
 PROCEDURE media;

 INTERFACE RETURNS media, total.entrada, total.valido;


 INTERFACE ACCEPTS valor, mínimo, máximo;

 TYPE valor [1:100] IS SCALAR ARRAY; Obtención de


 TYPE media, total, entrada, total.valido;
 Minimo, maximo, suma IS SCALAR casos de prueba
 TYPE i IS INTEGER
 I = 1;
 Total.entrada = total.valido
 suma = 0
 DO WHILE VALOR [i] <> -999 and total.entrada < 100
 Incrementar total.entrada en 1;
 IF valor [i] > = minimo AND valor [i] < = maximo
 THEN incrementar total.valido en 1;
 suma = suma + valor [i];
 ELSE ignorar
 ENDIF
 Incrementar i en 1;
 ENDDO
 IF total.valido > 0
 THEN media = suma/total.valido;
 ELSE MEDIA = -999;
 ENDIF
END media
 PROCEDURE media;

 INTERFACE RETURNS media, total.entrada, total.valido;


 INTERFACE ACCEPTS valor, mínimo, máximo;

 TYPE valor [1:100] IS SCALAR ARRAY;


 TYPE media, total, entrada, total.valido;
 Minimo, maximo, suma IS SCALAR
 TYPE i IS INTEGER
 I = 1;
 Total.entrada = total.valido
1 suma = 0
2
 DO WHILE VALOR [i] <> -999 and total.entrada < 3100
 Incrementar total.entrada en 1;
4
IF valor [i] > = minimo AND valor [i] < = maximo
6

 5 THEN incrementar total.valido en 1;



7 suma = suma + valor [i];
 ELSE ignorar
 ENDIF
 8 Incrementar i en 1;
 ENDDO
9
 IF total.valido > 0 1

1 THEN media = suma/total.valido;
0

1 ELSE MEDIA = -999;
1 2ENDIF

END media
3
 PROCEDURE media;

 INTERFACE RETURNS media, total.entrada, total.valido;


 INTERFACE ACCEPTS valor, mínimo, máximo;

 TYPE valor [1:100] IS SCALAR ARRAY; 1


 TYPE media, total, entrada, total.valido;
Minimo, maximo, suma IS SCALAR 2

 TYPE i IS INTEGER
 I = 1;
 Total.entrada = total.valido 1 3
1  suma = 0
2 0
 DO WHILE VALOR [i] <> -999 and total.entrada < 3 100 4
6 1
 Incrementar total.entrada en 1;
4 1
 IF valor [i] > = minimo AND valor [i] < = maximo
 5 THEN incrementar total.valido en 1; 1 5

7 suma = suma + valor [i]; 3
 ELSE ignorar 6
 ENDIF
8 Incrementar i en 1; 7
 ENDDO 8
9 IF total.valido > 0
1

1 THEN media = suma/total.valido;
0

1 ELSE MEDIA = -999; 9
1  2 ENDIF
3 END media
GRAFO DE FLUJO

1
V(G) = 6 regiones
V(G) = 17 aristas – 13 nodos +2 = 6
2 V(G) = 5 nodos predicado + 1 = 6

3
1
4 Conjunto básico de caminos linealmente
0
Independientes:
1 1
2 1 5
C1: 1-2-10-11-13
1 C2: 1-2-10-12-13
3 6 C3: 1-2-3-10-11-13
7 C4: 1-2-3-4-5-8-9-2……
8 C5: 1-2-3-4-5-6-8-9-2….
C6: 1-2-3-4-5-6-7-8-9-2…..

9
CASOS DE PRUEBAS
Caso prueba C1:
Valor (k)= entrada.valida, donde k < i

Valor (i)= -999, donde 2 <= i <= 100

Resultados esperados: media correcta sobre los k

valores y totales adecuados.


Caso prueba C2:

Valor (1) = -999

Resultados esperados: media = -999; otros totales

con sus valores iniciales


Caso prueba C3:

Intento de procesar más de 101 valores

Los primeros 100 valores deben ser válidos

Resultados esperados: igual que en el C1


CASOS DE PRUEBAS
Caso prueba C4:
Valor (i)= entrada.valida, donde 1 < 100

Valor (k)< a minimo, para k < i

Resultados esperados: media correcta sobre los k

valores y totales adecuados.


Caso prueba C5:

Valor (i)= entrada.valida, donde 1 < 100

Valor (k)> a maximo, para k < = i

Resultados esperados: media correcta sobre los n

valores y totales adecuados.


Caso prueba C6:

Valor (i)= entrada.valida, donde 1 < 100

Resultados esperados: media correcta sobre los n

valores y totales adecuados.


Abrir archivos;
Leer archivo ventas, al final indicar no más registros
Limpiar línea de impresión
WHILE (haya reg. ventas) DO
1-Total nacional = 0
Total extranjero = 0
WHILE (haya reg. Ventas y (mismo producto)
IF (nacional) THEN
Sumas venta nacional a total nacional
ELSE
Sumar venta extranjero a total extranjero
ENDIF;
Leer archivo ventas, al final indicar no más registros
ENDWHILE;
Escribir línea de listado;
Limpiar área de impresión;
ENDWHILE;
Cerrar archivos