Tema 09

Tema 9.
Pruebas del Software

1. Definiciones asociadas
2. El proceso de prueba
3. Tcnicas de diseo de casos de prueba
4. Pruebas estructurales
5. Pruebas funcionales
6. Pruebas aleatorias
7. Enfoque prctica de diseo de casos
8. Documentacin del diseo de pruebas
9. Ejecucin de pruebas
10. Estrategia de aplicacin de pruebas en el
ciclo de vida
PRUEBAS DEL SOFTWARE
12.005
Activid.
1
Activid.
2
.........
Pruebas
Activ.
N-1
Ciclo de vida
software
Controles
.........
Pretenden una evaluacin de
la calidad de los productos
generados
Todo Sistema debe haber sido probado
exhaustivamente a travs de una ejecucin
controlada antes de ser entregado al
cliente
Cuando ya dispongamos del
cdigo ejecutable de la
aplicacin
12.010
Verificacin: El proceso de evaluacin de un
sistema (o de uno de sus componentes para determinar
si los productos de una fase dada satisfacen las
condiciones impuestas al comienzo de dicha fase
Validacin: El proceso de evaluacin de un sistema
o de uno de sus componentes durante o al final del
proceso de desarrollo para determinar si satisface los
requisitos marcados por el usuario
Estamos
construyendo
correctamente
el producto?
Estamos
construyendo el
producto correcto?
12.020
DEFINICIONES
DEFINICIONES
Pruebas (test): una actividad en la cual un sistema o uno de sus
componentes se ejecuta en circunstancias previamente
especificadas, los resultados se observan y registran y se realiza
una evaluacin de algn aspecto
Caso de prueba (test case): un conjunto de entradas, condiciones
de ejecucin y resultados esperados desarrollados para un objetivo
particular
Defecto (defect, fault, bug): un defecto en el software como,
por ejemplo, un proceso, una definicin de datos o un paso de
procesamiento incorrectos en un programa
Proceso de
ejecutar un
programa
con el fin de
encontrar
errores
Instruccin
incorrecta
12.030
DEFINICIONES
DEFINICIONES
Fallo (failure): La incapacidad de un sistema o de alguno de sus
componentes para realizar las funciones requeridas dentro de los
requisitos de rendimiento especificados
Error (error): tiene varias acepciones:
La diferencia entre un valor calculado, observado o medio y
el valo verdadero, especificado o tericamente correcto.
Un defecto
Un resultado incorrecto
Una accin humana que conduce a un resultado incorrecto .
Error
Fallo
Defecto
Fallo
2 + 2 = 5
Error
Defecto (calidad)
Xyx//
???
Sistema de gestin de aeropuerto
Fallo (fiabilidad)
S.Aproximacin
Accidente
(seguridad)
Equivocacin
del programador
12.040
RELACION ENTRE ERROR, DEFECTO Y FALLO
RELACION ENTRE ERROR, DEFECTO Y FALLO
Error Defecto Fallo Efectos negativos
(del programador) (en el software) (el sistema no se (dependiendo de la
comporta como debera) criticidad del sistema)
Se Plasma
Da lugar a Que provoca
12.045
IDEAS PARADGICAS DE LAS PRUEBAS
IDEAS PARADGICAS DE LAS PRUEBAS
La prueba exhaustiva del software es impracticable (no se
pueden probar todas las posibilidades de su
funcionamiento ni siquiera en programas sencillos
El objetivo de las pruebas es la deteccin de defectos en el
software (descubrir un error es el xito de una prueba)
Mito un defecto implica que somos malos profesionales y que
debemos sentirnos culpables todo el mundo comete errores
El descubrimiento de un defecto significa un xito para la
mejora de la calidad
12.050
RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS
Cada caso de prueba debe definir el resultado de salida esperado que
se comparar con el realmente obtenido.
El programador debe evitar probar sus propios programas, ya que
desea (consciente o inconscientemente) demostrar que funcionan sin
problemas.
Adems, es normal que las situaciones que olvid considerar al crear el
programa queden de nuevo olvidados al crear los casos de prueba
Se debe inspeccionar a conciencia el resultado de cada prueba, as,
poder descubrir posibles sntomas de defectos.
Al generar casos de prueba, se deben incluir tanto datos de entrada
vlidos y esperados como no vlidos e inesperados.
12.060
Las pruebas deben centrarse en dos objetivos (es habitual olvidar
el segundo):
Se deben evitar los casos desechables, es decir, los no documentados
ni diseados con cuidado.
No deben hacerse planes de prueba suponiendo que, prcticamente,
no hay defectos en los programas y, por lo tanto, dedicando pocos
recursos a las pruebas siempre hay defectos
lProbar si el software no hace lo que debe hacer
lProbar si el software hace lo que debe hacer, es decir,
si provoca efectos secundarios adversos
Ya que suele ser necesario probar muchas veces el software y por tanto hay
que tener claro qu funciona y qu no
12.070
La experiencia parece indicar que donde hay un defecto hay otros,
es decir, la probabilidad de descubrir nuevos defectos en una parte
del software es proporcional al nmero de defectos ya descubierto.
Las pruebas son una tarea tanto o ms creativa que el desarrollo de
software. Siempre se han considerado las pruebas como una tarea
destructiva y rutinaria.
Es interesante planificar y disear las pruebas para poder detectar
el mximo nmero y variedad de defectos con el mnimo consumo
de tiempo y esfuerzo
12.080
CICLO COMPLETO DE LAS PRUEBAS
CICLO COMPLETO DE LAS PRUEBAS
12.090
PROCESO DE PRUEBA
PROCESO DE PRUEBA
+La depuracin (localizacin y correccin
de defectos)
+El anlisis de la estadstica de errores
ACTIVIDADES ACTIVIDADES
Sirve para realizar predicciones de la fiabilidad del
software y para detectar las causas ms habituales de
error y por tanto mejorar los procesos de desarrollo
12.100
ENFOQUES DE DISEO DE PRUEBAS
ENFOQUES DE DISEO DE PRUEBAS
Existen tres enfoques principales para el diseo de casos:
1.- El enfoque estructural o de caja blanca. Se centra en la
estructura interna del programa (analiza los caminos de
ejecucin).
2.- El enfoque funcional o de caja negra. Se centra en las
funciones, entradas y salidas.
3.- El enfoque aleatorio consiste en utilizar modelos
(en muchas ocasiones estadsticos) que representen
las posibles entradas al programa para crear a partir
de ellos los casos de prueba
12.110
LOS ENFOQUES DE DISEO DE PRUEBAS
LOS ENFOQUES DE DISEO DE PRUEBAS
DE CAJA BLANCA Y DE CAJA NEGRA
DE CAJA BLANCA Y DE CAJA NEGRA
Caja blanca
Caja negra
Entrada
Entrada
Salida
Salida
Funciones
Estructural
Funcional
12.120
PRUEBAS ESTRUCTURALES
GRAFO DE FLUJO DE UN PROGRAMA (PSEUDOCODIGO) GRAFO DE FLUJO DE UN PROGRAMA (PSEUDOCODIGO)
1
2
4
3
6
5
12,13
7a 7b
8,9
10,11
Abrir archivos;
Leer archivo ventas, al final indicar no ms registros;
Limpiar lnea de impresin;
WHILE (haya registros ventas) DO
Total nacional = 0;
Total extranjero = 0;
WHILE (haya reg. ventas) y (mismo producto)
IF (nacional) THEN
Sumar venta nacional a total nacional
ELSE
Sumar venta extranjero a total extranjero
ENDIF;
Leer archivo ventas, al final indicar no ms registros;
ENDWHILE;
Escribir lnea de listado;
Limpiar rea de impresin;
ENDWHILE;
Cerrar archivos.
de que se descubren defectos (un programa de 50 lneas con 25 sentencias if en serie da lugar a 33,5
millones de secuencias posibles), para lo que se usan los criterios de cobertura lgica.
El diseo de casos
de prueba tiene
que estar basado
en la eleccin de
caminos
importantes que
ofrezcan una
seguridad
aceptable
12.130
GRAFO DE FLUJO DE LAS ESTRUCTURAS BASICAS DE PROGRAMA GRAFO DE FLUJO DE LAS ESTRUCTURAS BASICAS DE PROGRAMA
x
x
x
Secuencia Si x entonces...
(If x then...else...)
Mientras x hacer...
(While x do...)
Hacer... hasta x
(Do...until x)
Repetir
Consejos:
-Separar todas las condiciones
-Agrupar sentencias simples en bloques
-Numerar todos los bloques de sentencias y tambin las condiciones
12.140
CRITERIOS DE COBERTURA LGICA CRITERIOS DE COBERTURA LGICA
E Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que
cada sentencia o instruccin del programa se ejecute al menos una vez.
E Cobertura de decisiones. Consiste en escribir casos suficientes para que cada
decisin tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno
falso. (Incluye a la cobertura de sentencias)
E Cobertura de condiciones. Se trata de disear tantos casos como sea necesario para
que cada condicin de cada decisin adopte el valor verdadero al menos una vez y el
falso al menos una vez. (No incluye cobertura de condiciones)
E Criterio de decisin/condicin. Consiste en exigir el criterio de cobertura de
condiciones obligando a que se cumpla tambin el criterio de decisiones.
E Criterio de condicin mltiple. En el caso de que se considere que la evaluacin de
las condiciones de cada decisin no se realiza de forma simultnea, se puede
considerar que cada decisin multicondicional se descompone en varias condiciones
unicondicionales. Ejemplo en la siguiente diapositiva.
E Criterio de cobertura de caminos. Se recorren todos los caminos (impracticable)
Menos riguroso
(ms barato)
Ms riguroso
(ms caros)
12.150
EJEMPLO DE DESCOMPOSICION DE UNA EJEMPLO DE DESCOMPOSICION DE UNA
DECISION MULTICONDICIONAL DECISION MULTICONDICIONAL
(a=1) and (c=4)
then
else
then
else
(a=1) (c=4)
12.160
LA COMPLEJIDAD DE LA COMPLEJIDAD DE McCABE McCABE V(G) (COMPLEJIDAD CICLOMTICA) V(G) (COMPLEJIDAD CICLOMTICA)
1. V (G) = a - n + 2, siendo a el nmero de arcos o aristas
del grafo y n el nmero de nodos.
2. V (G) = r, siendo r el nmero de regiones cerradas del
grafo.
3. V(G) = c + 1, siendo c el nmero de nodos de condicin.
La mtrica de McCabe ha sido muy popular en el diseo de pruebas
Es un indicador del nmero de caminos independientes que existen en un
grafo
La complejidad de
McCabe se puede
calcular de
cualquiera de estas 3
formas
12.165
LA COMPLEJIDAD DE LA COMPLEJIDAD DE McCABE McCABE V(G) V(G)
El criterio de prueba de McCabe es: Elegir tantos casos de prueba como
caminos independientes (calculados como V(G))
La experiencia en este campo asegura que:
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 quizs sea interesante dividir el mdulo
12.170
CALCULO DE LA COMPLEJIDAD CICLOMATICA SOBRE UN GRAFO CALCULO DE LA COMPLEJIDAD CICLOMATICA SOBRE UN GRAFO
1 2 4 3 6 5
1
1
7
8
9
1
0
a
1
a
2
a
3
a
4
a
5
a
6
a
7
a
8
a
9
a
1
0
a
1
1
a
1
2
a
1
3
a
1
4
R
e
g
i
n

2
R
e
g
i
n

4
R
e
g
i
n

3
R
e
g
i
n

1
R
e
g
i
n

5
a
)
V
(
G
)

=

1
4
-
1
1
+
2

=

5
b
)
V
(
G
)

=

5

r
e
g
i
o
n
e
s

c
e
r
r
a
d
a
s
c
)
V
(
G
)

=

5

c
o
n
d
i
c
i
o
n
e
s
12.180
PRUEBAS FUNCIONALES
PRUEBAS FUNCIONALES
Reduce el nmero de otros casos necesarios para que la prueba sea
razonable. Esto implica que el caso ejecute el mximo nmero de
posibilidades de entrada diferentes para as reducir el total de casos.
Cubre un conjunto extenso de otros casos posibles, es decir, no indica
algo acerca de la ausencia o la presencia de defectos en el conjunto
especfico de entradas que prueba, as como de otros conjuntos
similares.
Se centran en las funciones, entradas y salidas Es impracticable probar el
software para todas las posibilidades. De nuevo hay que tener criterios para
elegir buenos casos de prueba
Un caso de prueba funcional es bien elegido si se cumple que: Un caso de prueba funcional es bien elegido si se cumple que:
12.190
PRUEBAS FUNCIONALES
PRUEBAS FUNCIONALES
TCNICA: PARTICIPACIONES O CLASES DE EQUIVALENCIA TCNICA: PARTICIPACIONES O CLASES DE EQUIVALENCIA
Cada caso debe cubrir el mximo nmero de entradas
Debe tratarse el dominio de valores de entrada dividido en un
nmero finito de clases de equivalencia que cumplan la siguiente
propiedad: la prueba de un valor representativo de una clase
permite suponer razonablemente que el resultado obtenido
(existan defectos o no) ser el mismo que el obtenido probando
cualquier otro valor de la clase
C
u
a
l
i
d
a
d
e
s

q
u
e

d
e
f
i
n
e
n

u
n

b
u
e
n

c
a
s
o

d
e

p
r
u
e
b
a
Identificar clases de equivalencia
Crear casos de prueba correspondiente
Lo que hay que hacer es:
12.200
PRUEBAS FUNCIONALES
PRUEBAS FUNCIONALES
PARTICIPACIONES O CLASES DE EQUIVALENCIA PARTICIPACIONES O CLASES DE EQUIVALENCIA
PASOS PARA IDENTIFICAR CLASES DE EQUIVALENCIA PASOS PARA IDENTIFICAR CLASES DE EQUIVALENCIA
1. Identificacin de las condiciones de las entradas del programa, es decir,
restricciones de formato o contenido de los datos de entrada
2. A partir de ellas, se identifican clases de equivalencia que pueden ser:
a) De datos vlidos
b) De datos no vlidos o errneos
3. Existen algunas reglas que ayudan a identificar clase:
a) Si se especifica un rango de valores para los datos de entrada, secrear una clase vlida y
dos clases no vlidas
b) Si se especifica un nmero finito y consecutivo de valores, se crear una clase vlida y dos
no vlidas
12.210
c) Si se especifica una situacin del tipo debe ser o booleana (por
ejemplo, el primer carcter debe ser una letra), se identifican una
clase vlida (es una letra) y una no vlida (no es una letra)
d) Si se especifica un conjunto de valores admitidos y se sabe que el
programa trata de forma diferente cada uno de ellos, se identifica una
clase vlida por cada valor y una no vlida
e) En cualquier caso, si se sospecha que ciertos elementos de una clase
no se tratan igual que el resto de la misma, deben dividirse en clases
menores
PRUEBAS FUNCIONALES
PRUEBAS FUNCIONALES
PASOS PARA IDENTIFICAR CLASES DE EQUIVALENCIA PASOS PARA IDENTIFICAR CLASES DE EQUIVALENCIA
12.220
El ltimo paso del mtodo es el uso de las clases de equivalencia para identificar los
casos de prueba correspondientes. Este proceso consta de las siguientes fases:
+ Asignacin de un nmero nico a cada clase de equivalencia
+ Hasta que todas las clases de equivalencia vlidas hayan sido cubiertas
por (incorporadas a) casos de prueba, se tratar de escribir un caso que
cubra tantas clases vlidas no incorporadas como sea posible
+ Hasta que todas las clases de equivalencia no vlidas hayan sido
cubiertas por casos de prueba, escribir un caso para una nica clase no
vlida sin cubrir
PRUEBAS FUNCIONALES
PRUEBAS FUNCIONALES
PASOS PARA IDENTIFICAR CASOS DE PRUEBA PASOS PARA IDENTIFICAR CASOS DE PRUEBA
12.230
PRUEBAS FUNCIONALES
PRUEBAS FUNCIONALES
TABLA DE CLASES DE EQUIVALENCIA DEL EJEMPLO TABLA DE CLASES DE EQUIVALENCIA DEL EJEMPLO
Condicin de entrada Clases vlidas Clases invlidas
Cdigo rea (1) 200
cdigo
999 (2) cdigo <200

(3) cdigo >999
(4) no es nmero
Nombre para identificar la
operacin
(5) seis caracteres (6) menos de 6 caracteres
(7) ms de 6 caracteres
Orden (8) cheque
(9)
(10)
(11)
(12) ninguna orden vlida
depsito
pago factura
retirada de fondos
Ejemplo: Aplicacin bancaria en la que el operador debe proporcionar un cdigo, un
nombre y una operacin
Habra que disear casos de prueba que cubran todas las clases de equivalencia, tanto
vlidas como invlidas, y para las invlidas en casos de prueba distintos
N de 3 dgitos que no
empieza con 0 ni 1)
Una de las siguientes
12.240
PRUEBAS FUNCIONALES
PRUEBAS FUNCIONALES
TCNICA: ANALISIS DE VALORES LIMITE (AVL) TCNICA: ANALISIS DE VALORES LIMITE (AVL)
Ms que elegir cualquier elemento como representativo
de una clase de equivalencia, se requiere la seleccin de
uno o ms elementos tal que los mrgenes se sometan a
prueba
Ms que concentrarse nicamente en el dominio de entrada
(condiciones de entrada), los casos de prueba se generan
considerando tambin el espacio de salida
La experiencia indica que los casos de prueba que exploran las condiciones
lmite de un programa producen un mejor resultado para detectar defectos
El AVL es una tcnica de diseo de casos de prueba que complementa a la
de particiones de equivalencia. Las diferencias son las siguientes:
12.250
PRUEBAS FUNCIONALES
PRUEBAS FUNCIONALES
ANALISIS DE VALORES LIMITE (AVL) ANALISIS DE VALORES LIMITE (AVL)
LAS REGLAS PARA IDENTIFICAR CLASES SON: LAS REGLAS PARA IDENTIFICAR CLASES SON:
1. Si una condicin de entrada especifica un rango de valores, se deben generar
casos para los extremos del rango y casos no vlidos para situaciones justo ms
all de los extremos
2. Si la condicin de entrada especifica un nmero finito y consecutivo de valores, hay que
escribir casos para los nmeros mximo, mnimo, uno ms del mximo y uno menos del
mnimo de valores
3. Usar la regla 1 para la condicin de salida
4. Usar la regla 2 para cada condicin de salida
+Los valores lmite de entrada no generan necesariamente los valores
lmite de salida (recurdese la funcin seno, por ejemplo)
+No siempre se pueden generar resultados fuera del rango de salida
(pero es interesante considerarlo)
5. Si la entrada o la salida de un programa es un conjunto ordenado, los
casos se deben concentrar en el primero y en el ltimo elemento
12.260
PRUEBAS FUNCIONALES
PRUEBAS FUNCIONALES
TCNICA: CONJETURA DE ERRORES TCNICA: CONJETURA DE ERRORES
EEl valor cero es una situacin propensa a error tanto en la salida como
en la entrada
EEn situaciones en las que se introduce un nmero variable de valores,
conviene centrarse en el caso de no introducir ningn valor y en el de
un solo valor. Tambin puede ser interesante un lista que tiene todos
los valores iguales
EEs recomendable imaginar que el programador pudiera haber interpretado
algo mal en la especificacin
ETambin interesa imaginar lo que el usuario puede introducir como entrada
a un programa
Se enumera una lista de posibles equivocaciones tpicas que pueden cometer los
desarrolladores y de situaciones propensas a ciertos errores
...
12.270
PRUEBAS ALEATORIAS
PRUEBAS ALEATORIAS
En las pruebas aleatorias simulamos la entrada habitual
del programa creando datos de entrada en la secuencia
y con la frecuencia con las que podran aparecer en la
Prctica (de manera repetitiva)
Para ello habitualmente se utilizan generadores automticos de
casos de prueba
12.280
ENFOQUE PRACTICO RECOMENDADO PARA
EL DISEO DE CASOS
EL DISEO DE CASOS
- Si la especificacin contiene combinaciones de condiciones
de entrada, comenzar formando sus grafos de causa-efecto
(ayudan a la comprensin de dichas combinaciones)
-En todos los casos, usar el anlisis de valores lmites para
aadir casos de prueba: elegir lmites para dar valores a las
causas en los casos generados asumiendo que cada causa es
una clase de equivalencia
-Identificar las clases vlidas y no vlidas de equivalencia
para la entrada y la salida, y aadir los casos no incluidos
anteriormente
Se propone un uso ms apropiado de cada tcnica (caja blanca y negra) para
obtener un conjunto de casos tiles:
-Utilizar la tcnica de conjetura de errores para aadir
nuevos casos, referidos a valores especiales
12.290
EL DISEO DE CASOS
EL DISEO DE CASOS
-Ejecutar los casos generados hasta el momento y analizar
la cobertura obtenida
-Examinar la lgica del programa para aadir los casos
precisos (de caja blanca) para cumplir el criterio de
cobertura elegido si los resultados de la ejecucin del
punto anterior indican que no se ha satisfecho el criterio
de cobertura elegido
12.300
Los errores lgicos y las suposiciones incorrectas son inversamente
proporcionales a la probabilidad de que se ejecute un camino del programa ( a
menor probabilidad de ejecutarse un camino, mayor nmero de errores)
Se suele creer que un determinado camino lgico tiene pocas posibilidades de
ejecutarse cuando, de hecho, se puede ejecutar regularmente
Los errores tipogrficos son aleatorios; pueden aparecer en cualquier parte del
programa (sea muy usada o no)
La probabilidad y la importancia de un trozo de cdigo suele ser calculada de
forma muy subjetiva
Una cuestin importante es por qu son necesarias las pruebas de caja blanca
si comprobamos que las funciones se realizan correctamente?
No obstante las pruebas de caja blanca slas tampoco garantizan el xito:
if (x+y+z)/3=x then print (x,y y z son iguales) else print (x,y y z no son iguales)
Una prueba de caja blanca como esta
x=5 y=5 z=5 x=2 y=3 z=7^12
No detecta el error lgico, que si sera detectado con otro tipo de pruebas funcionales.
12.310
DOCUMENTOS RELACIONADOS CON EL DISEO
DOCUMENTOS RELACIONADOS CON EL DISEO
DE LAS PRUEBAS SEGUN EL ESTANDAR IEEE
DE LAS PRUEBAS SEGUN EL ESTANDAR IEEE
std
std
. 829
. 829
Documentacin
Plande
Pruebas
Especificacin
de diseo
de las pruebas
Especificacin
de diseo
de las pruebas
...............
Especificacin
de caso de
prueba
Especificacin
de procedimiento
de pruebas
EJECUCIN
Informes
12.320
PLAN DE PRUEBAS
PLAN DE PRUEBAS
Objetivo del documento
Sealar el enfoque, los recursos y el esquema de actividades
de prueba, as como los elementos a probar, las caractersticas,
las actividades de prueba, el personal responsable y los riesgos
asociados
12.330
PLAN DE PRUEBAS
PLAN DE PRUEBAS
1. Identificador nico del documento
2. Introduccin y resumen de elementos y caractersticas a probar
3. Elementos software a probar
4. Caractersticas a probar
5. Caractersticas que no se probarn
6. Enfoque general de la prueba
7. Criterios de paso/fallo para cada elemento
8. Criterios de suspensin y requisitos de reanudacin
9. Documentos a entregar
10. Actividades de preparacin y ejecucin de pruebas
11. Necesidades de entorno
12. Responsabilidades en la organizacin y realizacin de las pruebas
13. Necesidades de personal y formacin
14. Esquema de tiempos
15. Riesgos asumidos por el plan y planes de contingencias
16. Aprobaciones y firmas con nombre y puesto desempeado
Estructura fijada en el estndar
12.340
ESPECIFICACION DEL DISEO DE PRUEBAS
Especificar los refinamientos necesarios sobre el enfoque
general reflejado en el plan e identificar las caractersticas
que se deben probar con este diseo de pruebas
Identificador nico para la especificacin. Proporcionar tambin una
referencia del plan asociado (si existe)
Caractersticas a probar de los elementos software (y combinaciones
de caractersticas)
Detalles sobre el plan de pruebas del que surge este diseo, incluyendo
las tcnicas de prueba especfica y los mtodos de anlisis de resultados
Identificacin de cada prueba:
-identificador
-casos que se van a utilizar
-procedimientos que se van a seguir
Criterios de paso/fallo de la prueba (criterios para determinar si una
caracterstica o combinacin de caractersticas ha pasado con xito
la prueba o no)
12.350
12.360
ESPECIFICACION DE CASO DE PRUEBA
Definir uno de los casos de prueba identificando
por una especificacin del diseo de las pruebas
Identificador nico de la especificacin
Elementos software (por ejemplo, mdulos) que se van a probar:
definir dichos elementos y las caractersticas que ejercitar este caso
Especificaciones de cada entrada requerida para ejecutar el caso
(incluyendo las relaciones entre las diversas entradas; por ejemplo,
la sincronizacin de las mismas)
Especificaciones de todas las salidas y las caractersticas requeridas
(por ejemplo, el tiempo respuesta) para los elementos que se van a probar
Necesidades de entorno (hardware, software y otras como, por ejemplo,
el personal)
Requisitos especiales de procedimiento (o restricciones especiales en los
procedimientos para ejecutar este caso).
Dependencias entre casos (por ejemplo, listar los identificadores de los
casos que se van a ejecutar antes de este caso de prueba)
12.370
12.380
ESPECIFICACION DE PROCEDIMIENTO
DE PRUEBA
DE PRUEBA
Especificar los pasos para la ejecucin de un conjunto
de casos de prueba o, ms generalmente, los pasos
utilizados para analizar un elemento software con el
propsito de evaluar un conjunto de caractersticas
del mismo
Identificador nico de la especificacin y referencia a la correspondiente
especificacin de diseo de prueba
Objetivo del procedimiento y lista de casos que se ejecutan con l
Requisitos especiales para la ejecucin (por ejemplo, entorno especial o
personal especial)
Pasos en el procedimiento. Adems de la manera de registrar los resultados
y los incidentes de la ejecucin, se debe especificar:
-La secuencia necesaria de acciones para preparar la ejecucin
-Acciones necesarias para empezar la ejecucin
-Acciones necesarias durante la ejecucin
-Cmo se realizarn las medidas ( por ejemplo, el tiempo de respuesta)
-Acciones necesarias para suspender la prueba (cuando los acontecimientos no
previstos lo obliguen)
-Puntos para reinicio de la ejecucin y acciones necesarias para el reinicio en estos puntos
-Acciones necesarias para detener ordenadamente la ejecucin
-Acciones necesarias para restaurar el entorno y dejarlo en la situacin existente antes
de las pruebas
-Acciones necesarias para tratar los acontecimientos anmalos
12.390
DE PRUEBA
DE PRUEBA
12.400
PROCESO DE PRUEBAS, TRAS EL DISEO DE
PROCESO DE PRUEBAS, TRAS EL DISEO DE
CASOS, SEGUN EL ESTANDAR IEEE 1008
CASOS, SEGUN EL ESTANDAR IEEE 1008
1.EJECUTAR
2.COMPROBAR
SI TERMIN
LA PRUEBA
3.EVALUAR
RESULTADOS
3.PRUEBAS
ADICIONALES
12.410
DETALLES DEL PROCESO
DETALLES DEL PROCESO
EJECUTAR
EJECUTAR
EJECUTAR
PRUEBAS
ALGUN
FALLO?
No
COMPROBAR
TERMINACIN
DEPURAR
LAS
PRUEBAS
DEPURACIN
DEFECTOS
EN LAS
PRUEBAS
DEFECTOS
SOFTWARE
Si Si
DEL
CDIGO
12.420
DETALLES DEL PROCESO DE COMPROBACION
DETALLES DEL PROCESO DE COMPROBACION
DE LA TERMINACION DE LAS PRUEBAS
DE LA TERMINACION DE LAS PRUEBAS
PRUEBAS
ADICIONALES
EJECUCIN
CONDICIONES
ANORMALES
Pruebas
adicionales?
No Si
EVALUACIN
Criterios de
complec
in
descritos
en el plan de pruebas
TERMINACIN
ANORMAL
TERMINACIN
NORMAL
No
12.430
DOCUMENTACION RELACIONADA CON LA EJECUCION
DOCUMENTACION RELACIONADA CON LA EJECUCION
DE LAS PRUEBAS SEGUN EL ESTANDAR IEEE 829
DE LAS PRUEBAS SEGUN EL ESTANDAR IEEE 829
Casos
procedimientos
Especificacin
de las pruebas
EJECUCION
Histrico
de
pruebas
Informe
de
incidente
Histrico
de
pruebas
Informe
de
incidente
Ejecucin
Ejecucin
Informe
Resmen
Se pueden
distinguir
histricos,
incidencias y
resmenes
12.440
Objetivo
El histrico de pruebas (test log) documenta
todos los hechos relevantes ocurridos durante
la ejecucin de las pruebas
HISTORICO DE PRUEBAS
12.450
Estructura fijada en el estndar:
Identificador
Descripcin de la prueba: elementos probados y entorno de la prueba
Anotacin de datos sobre cada hecho ocurrido (incluido el comienzo
y el final de la prueba)
-Fecha y hora
-Identificador de informe de incidente
Otras informaciones
12.460
Objetivo:
INFORME DE INCIDENTE
El informe de incidente (test incident report) documenta
cada incidente (por ejemplo, una interrupcin en las
pruebas debido a un corte de electricidad, bloqueo del
teclado, etc.) ocurrido en la prueba y que requiera una
posterior investigacin.
12.470
Identificador
Resumen del incidente
Descripcin de datos objetivos (fecha/hora, entradas,
resultados esperados, etc)
Impacto que tendr sobre las pruebas
12.480
Objetivo:
INFORME RESUMEN DE PRUEBAS
INFORME RESUMEN DE PRUEBAS
El informe resumen (test summary report)
resume los resultados de las actividades
de prueba (las sealadas en el propio informe)
y aporta una evaluacin del software basada
en dichos resultados
12.490
INFORME RESUMEN DE LAS PRUEBAS
INFORME RESUMEN DE LAS PRUEBAS
Identificador
Resumen de la evaluacin de los elementos probados
Variaciones del software respecto a su especificacin de diseo, as
como las variaciones en las pruebas
Valoracin de la extensin de la prueba (cobertura lgica, funcional,
de requisitos, etc.)
Resumen de los resultados obtenidos en las pruebas
Evaluacin de cada elemento software sometido a prueba (evaluacin
general del software incluyendo las limitaciones del mismo)
Firmas y aprobaciones de quienes deban supervisar el informe
12.500
RELACION ENTRE LAS PRUEBAS Y LA DEPURACION
RELACION ENTRE LAS PRUEBAS Y LA DEPURACION
Casos
de
prueba
Ejecucin
Resultados
Causas
ignoradas
Correcciones
Causas
Depuracin
Sntomas
de
defectos
(errores)
Depuracin: el proceso de analizar y corregir los defectos que
se sospecha que contiene el software
12.510
CONSEJOS PARA LA DEPURACION
- Analizar la informacin y pensar (analizar bien, en lugar de aplicar un enfoque aleatorio
de bsqueda del defecto)
- Al llegar a un punto muerto, pasar a otra cosa (refresca la mente)
- Al llegar a un punto muerto, describir el problema a otra persona (el simple hecho de
describir el problema a alguien puede ayudar)
- Usar herramientas de depuracin slo como recurso secundario (no sustituir el anlisis
mental)
- No experimentar cambiando el programa (no s qu est mal, as que cambiar esto y
ver lo que sucede NO)
- Se deben atacar los errores individualmente
- Se debe fijar la atencin tambin en los datos (no slo en la lgica del programa)
Localizacin del error
12.520
- Donde hay un defecto, suele haber ms (lo dice la experiencia)
- Debe fijarse el defecto, no sus sntomas (no debemos enmascarar sntomas, sino corregir
el defecto)
- La probabilidad de corregir perfectamente un defecto no es del 100% (cuando se corrige,
hay que probarlo)
- Cuidado con crear nuevos defectos (al corregir defectos se producen otros nuevos)
- La correccin debe situarnos temporalmente en la fase de diseo (hay que retocar desde
el comienzo, no slo el cdigo)
- Cambiar el cdigo fuente, no el cdigo objeto
Correccin del error
12.530
ANALISIS DE ERRORES O ANALISIS CAUSAL
ANALISIS DE ERRORES O ANALISIS CAUSAL
Cundo se cometi?
Quin lo hizo
Qu se hizo mal?
Cmo se podra haber prevenido?
Por qu no se detect antes?
Cmo se podra haber detectado antes?
Cmo se encontr el error?
El objetivo del anlisis causal es proporcionar informacin sobre la
naturaleza de los defectos. Para ello es fundamental recoger para cada
defecto detectado esta informacin:
Esta informacin no debera ser usada para evaluar al personal, sino para la
formacin del mismo sobre cmo prevenir los errores. Tambin se utiliza para
predecir futuros fallos software
12.535
ESTRATEGIA DE APLICACIN DE LAS PRUEBAS
E Se analiza cmo plantear las pruebas en el Ciclo de Vida.
E La estrategia de pruebas suele seguir estas etapas
Comenzar pruebas a nivel de mdulo
Continuar hacia la integracin del sistema completo y a su
instalacin
Culminar con la aceptacin del producto por parte del cliente
12.540
ESe comienza en la prueba de cada mdulo, que normalmente la realiza
el propio personal de desarrollo en su entorno
ECon el esquema del diseo del software, los mdulos probados se integran
para comprobar sus interfaces en el trabajo conjunto (prueba de integracin)
EEl software totalmente ensamblado se prueba como un conjunto para comprobar
si cumple o no tanto los requisitos funcionales como los requisitos de rendimientos,
seguridad, etc. (prueba funcional o de validacin).
EEl software ya validado se integra con el resto del sistema (por ejemplo, elementos
mecnicos, interfaces electrnicas, etc.) para probar su funcionamiento conjunto
(prueba del sistema)
EPor ltimo, el producto final se pasa a la prueba de aceptacin para que el usuario
compruebe en su propio entorno de explotacin si lo acepta como est o no (prueba
de aceptacin)
E
t
a
p
a
s

t
p
i
c
a
s

m
s

e
n

d
e
t
a
l
l
e
RELACION ENTRE PRODUCTOS DE DESARROLLO
RELACION ENTRE PRODUCTOS DE DESARROLLO
Y NIVELES DE PRUEBA
Y NIVELES DE PRUEBA
12.550
Requisitos
de usuario
Especificac.
de requisitos
Diseo
modular
Especific. y
lgica de
mdulo
Cdigo
Pruebas de
unidad
Pruebas de
integracin
Pruebas de
sistema
Pruebas de
aceptacin
Existe una correspondencia entre cada nivel de prueba y el trabajo realizado en
cada etapa del desarrollo
El usuario comprueba que el
sistema hace lo especificado en
el contrato
Sistema (cumplimiento de
objetivos)
Validacin (desajustes entre el
software y los requisitos)
Agrupacin de mdulos
Interfaces
Lgica de mdulos (caja blanca)
Funciones (caja negra)
PRUEBA DE UNIDAD
PRUEBA DE UNIDAD
12.560
Hablamos de una unidad de prueba para referirnos a uno o ms mdulos
que cumplen las siguientes condiciones [IEEE, 1986a]:
Todos son del mismo programa
Al menos uno de ellos no ha sido probado
El conjunto de mdulos es el objeto de un proceso de prueba
Se trata de las pruebas formales que permiten declarar que un mdulo est listo y
terminado (no las informales que se realizan mientras se desarrollan los mdulos)
La prueba de unidad puede abarcar desde un mdulo hasta un grupo de mdulos
(incluso un programa completo)
Estas pruebas suelen realizarlas el propio personal de desarrollo, pero evitando que
sea el propio programador del mdulo
PRUEBAS DE INTEGRACION
12.570
Implican una progresin ordenada de pruebas que van desde
los componentes o mdulos y que culminan en el sistema
completo
El orden de integracin elegido afecta a diversos factores,
como lo siguientes:
La forma de preparar casos
Las herramientas necesarias
El orden de codificar y probar los mdulos
El coste de la depuracin
El coste de preparacin de casos
12.580
Tipos fundamentales de integracin
Integracin incremental. Se combina el siguiente mdulo
que se debe probar con el conjunto de mdulos que ya han
sido probados
Integracin no incremental. Se prueba cada mdulo por
separado y luego se integran todos de una vez y se prueba el
programa completo
;ascendente. Se comienza por los mdulos hoja.
+descendente. Se comienza por el mdulo raz.
Habitualmente las pruebas de unidad y de integracin se solapan y
mezclan en el tiempo.
12.580
INTEGRACIN INCREMENTAL ASCENDENTE
INTEGRACIN INCREMENTAL ASCENDENTE
El proceso es el siguiente
Se combinan los mdulos de bajo nivel en grupos que realicen una funcin
o subfuncin especfica (o quizs si no es necesario, individualmente) de
este modo reducimos el nmero de pasos de integracin.
Se escribe para cada grupo un mdulo impulsor o conductor de este
modo permitimos simular la llamada a los mdulos, introducir datos de
prueba y recoger resultados.
Se prueba cada grupo mediante su impulsor
Se eliminan los mdulos impulsores y se sustituyen por los mdulos de
nivel superior en la jerarqua.
DISEO MODULAR SOBRE EL QUE SE REALIZA
DISEO MODULAR SOBRE EL QUE SE REALIZA
LA INTEGRACION
LA INTEGRACION
12.590
A
D C B
E F G
Supongamos esta estructura de programa
PRIMERA FASE DE LA INTEGRACION
PRIMERA FASE DE LA INTEGRACION
ASCENDENTE DEL EJEMPLO
12.600
Impulsor de D
D
Impulsor de G
G
Impulsor de E
E
Impulsor de F
F
1 fase
Se definen los impulsores para nodos hoja y se
ejecutan
Pruebas de
Unidad
SEGUNDA Y TERCERA FASE DE LA INTEGRACION
SEGUNDA Y TERCERA FASE DE LA INTEGRACION
12.610
Impulsor de E Impulsor de F
C
F G
B
E
A
D C B
E F G
2 fase 3 fase
Prueba de unidad de E
Prueba de integracin de B con E
12.615
INTEGRACIN INCREMENTAL DESCENDENTE
INTEGRACIN INCREMENTAL DESCENDENTE
Comienza por el mdulo de control principal y va incorporando mdulos
subordinados progresivamente.
No hay un orden adecuado de integracin, pero unos consejos son los
siguientes:
-Si hay secciones crticas (especialmente complejas) se deben integrar lo antes
posible.
-El orden de integracin debe incorporar cuanto antes los mdulos de
entrada/salida para facilitar la ejecucin de puebas
Existen dos formas bsicas de hacer esta integracin:
-Primero en profundidad: Se van completando ramas del rbol (A B E C F G D)
-Primero en anchura: Se van completando niveles de jerarqua (A B C D E F G)
12.620
ETAPAS FUNDAMENTALES DE LA
ETAPAS FUNDAMENTALES DE LA
INTEGRACION DESCENDENTE
INTEGRACION DESCENDENTE
El mdulo raz es el primero: Se escriben mdulos ficticios que simulan
los subordinados
Una vez probado el mdulo raz (sin detectarse ya ningn defecto),
se sustituye uno de los subordinados ficticios por el mdulo
correspondiente segn el orden elegido
Se ejecutan las correspondientes pruebas cada vez que se incorpora
un mdulo nuevo
Al terminar cada prueba, se sustituye un ficticio por su correspondiente
real
Conviene repetir algunos casos de prueba de ejecuciones anteriores para
asegurarse de que no se ha introducido ningn defecto nuevo
12.630
MDULOS FICTICIOS
MDULOS FICTICIOS
Mdulos que slo muestran un mensaje de traza
Mdulos que muestran los parmetros que se les pasa
Mdulos que devuelven un valor que no depende de los
parmetros que se pasen como entrada
Mdulos que, en funcin de los parmetros pasados, devuelven
un valor de salida que ms o menos se corresponda con dicha
entrada
La creacin de mdulos ficticios subordinados es ms complicada que
la creacin de impulsores
-Complejidad
+Complejidad
UNA POSIBLE CLASIFICACION DE
UNA POSIBLE CLASIFICACION DE
LOS MODULOS FICTICIOS
LOS MODULOS FICTICIOS
12.640
Tipo 1 Tipo 2 Tipo 3 Tipo 4
Muestra Muestra Devuelve Recibe y
mensaje param. de entrada valor devuelve valor
UN PASO INTERMEDIO EN LA INTEGRACION
DESCENDENTE PRIMERO EN LA PROFUNDIDAD
DESCENDENTE PRIMERO EN LA PROFUNDIDAD
DEL EJEMPLO
DEL EJEMPLO
12.650
A
Ficticio D Ficticio C B
E
Recordar el recorrido de
rboles en profundidad
DESCENDENTE PRIMERO EN LA ANCHURA
DESCENDENTE PRIMERO EN LA ANCHURA
DEL EJEMPLO
DEL EJEMPLO
12.660
A
ficticio D C B
Ficticio E
Recordar el recorrido de
rboles en anchura
12.670
INTEGRACION NO INCREMENTAL
INTEGRACION NO INCREMENTAL
Un mdulo impulsor, que transmite o impulsa los datos
de prueba al mdulo y muestra los resultados de dichos
casos de prueba
Uno o ms mdulos ficticios que simulan la funcin
de cada mdulo subordinado llamado por el mdulo
que se va a probar
Cada mdulo que tiene que ser probado necesita lo siguiente:
Una vez probado cada mdulo por separado, se ensamblan todos de una vez y
se prueban en conjunto
PRUEBA TIPICA DEL MODULO EN LA INTEGRACION
PRUEBA TIPICA DEL MODULO EN LA INTEGRACION
NO INCREMENTAL
NO INCREMENTAL
12.680
Mdulo que se
va a probar
ficticio 3 ficticio 2 ficticio 1
Impulsor
Resultados
Casos de
prueba
COMPARACION DE LOS DISTINTOS
COMPARACION DE LOS DISTINTOS
TIPOS DE INTEGRACION
TIPOS DE INTEGRACION
12.690
Ventajas de la no incremental:
Requiere menos tiempo de mquina para las pruebas, ya que
se prueba de una sola vez la combinacin de los mdulos
Existen ms oportunidades de probar mdulos en paralelo
Ventajas de la incremental:
Requiere menos trabajo, ya que se escriben menos mdulos impulsores
y ficticios
Los defectos y errores en las interfaces se detectan antes, ya que se
empieza antes a probar las uniones entre los mdulos
La depuracin es mucho ms fcil, ya que si se detectan los sntomas
de un defecto en un paso de la integracin hay que atribuirlo muy
probablemente al ltimo mdulo incorporado
Se examina con mayor detalle el programa, al ir comprobando cada
interfaz poco a poco
VENTAJAS Y DESVENTAJAS DE LAS
VENTAJAS Y DESVENTAJAS DE LAS
INTEGRACIONES ASCENDENTE Y DESCENDENTE
INTEGRACIONES ASCENDENTE Y DESCENDENTE
Descendente
Es un mtodo ventajoso si aparecen
grandes fallos en la parte inferior del
programa, ya que se prueba antes.
La entradas para las pruebas son ms
mdulos inferiores tienen funciones
Ascendente
Ventajas

fciles de crear, puesto que los
ms especficas.
Es ms fcil observar los resultados de
la prueba, ya que es en los mdulos
inferiores donde se elaboran los datos
(los superiores suelen ser mdulos de
control).
Ventajas

Es ventajosa si aparecen grandes
defectos en los niveles superiores del
programa, ya que se prueban antes.

Una vez incorporadas las funciones de
entrada/salida, es fcil manejar los
casos de prueba.

Permite ver antes una estructura previa
del programa, lo que facilita el hacer
demostraciones y ayuda a mantener la
moral.
Desventajas

Se requieren mdulos impulsores, que
deben codificarse.

El programa, como entidad, slo
aparece cuando se agrega el ltimo
mdulo.
Desventajas

Se requieren mdulos ficticios que
suelen ser complejos de crear.

Antes de incorporar la entrada/salida
resulta complicado el manejo de los
casos de prueba.

Las entradas para las pruebas pueden
ser difciles o imposibles de crear,
puesto que, a menudo, se carece de
los mdulos inferiores que
proporcionan los detalles de operacin.

Es ms difcil observar la salida, ya
que los resultados surgen de los
mdulos inferiores.

Pueden inducir a diferir la terminacin
de la prueba de ciertos mdulos.
12.700
PRUEBA DEL SISTEMA
PRUEBA DEL SISTEMA
12.710
Cumplimiento de todos los requisitos funcionales, considerando
el producto software final al completo en un entorno de sistema
El funcionamiento y rendimiento en las interfaces hardware,
software, de usuario y de operador
Adecuacin de la documentacin de usuario
Ejecucin y rendimiento en condiciones lmite y de sobrecarga
Es el proceso de prueba de un sistema integrado de hardware y
software para comprobar lo siguiente:
FUENTES DE DISEO DE CASOS DE PRUEBA DEL SISTEMA
FUENTES DE DISEO DE CASOS DE PRUEBA DEL SISTEMA
12.720
Casos basados en los requisitos gracias a tcnicas de caja negra aplicadas
a las especificaciones
Casos necesarios para probar el rendimiento del sistema y de su capacidad
funcional (pruebas de volumen de datos, de lmites de procesamiento, etc.).
Este tipo de pruebas suelen llamarse pruebas de sobrecarga (stress testing)
Casos basados en el diseo de alto nivel aplicando tcnicas de caja blanca
a los flujos de datos de alto nivel (por ejemplo, de los diagramas de flujo
de datos)
PRUEBA DE ACEPTACION
PRUEBA DE ACEPTACION
12.730
- Participacin del usuario
- Est enfocada hacia la prueba de los requisitos de
usuario especificados.
- Est considerada como la fase final del proceso
para crear una confianza en que el producto es el
apropiado para su uso en explotacin
Es la prueba planificada y organizada formalmente para
determinar si se cumplen los requisitos de aceptacin marcados
por el cliente.
Sus caractersticas principales son las siguientes:
RECOMENDACIONES GENERALES
RECOMENDACIONES GENERALES
12.740
Debe contarse con criterios de aceptacin
previamente aprobados por el usuario
No hay que olvidar validar tambin la
documentacin y los procedimientos de uso
(por ejemplo,mediante una auditora)
Las pruebas se deben realizar en el entorno
en el que se utilizar el sistema (lo que incluye
al personal que lo maneja)

Tema 09

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 09

Cargado por

Copyright:

Formatos disponibles

Tema 9.

Pruebas del Software

999 (2) cdigo <200

También podría gustarte