Beruflich Dokumente
Kultur Dokumente
Definiciones asociadas
El proceso de prueba
Tcnicas de diseo de casos de prueba
Pruebas estructurales
Pruebas funcionales
Pruebas aleatorias
Enfoque prctica de diseo de casos
Documentacin del diseo de pruebas
Ejecucin de pruebas
Ciclo de vida
software
Activid.
1
Activid.
2
.........
.........
Activ.
N-1
Pruebas
Controles
Estamos
construyendo el
producto correcto?
DEFINICIONES
Proceso de
ejecutar un
programa
con el fin de
encontrar
errores
Instruccin
incorrecta
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:
Fallo
Defecto
Fallo
Error
Un defecto
Un resultado incorrecto
Una accin humana que conduce a un resultado incorrecto .
Error
Equivocacin
del programador
2+2=5
Accidente
(seguridad)
Defecto (calidad)
S.Aproximacin
Xyx//
???
Fallo (fiabilidad)
Se Plasma
Da lugar a Fallo
Que provoca
Error
Defecto
Efectos negativos
(del programador)
(en el software)
(el sistema no se
(dependiendo de la
comporta como debera)
criticidad del sistema)
PROCESO DE PRUEBA
ACTIVIDADES
Salida
Estructural
Caja negra
Funcional
Salida
Entrada
Funciones
PRUEBAS ESTRUCTURALES
GRAFO DE FLUJO DE UN PROGRAMA (PSEUDOCODIGO)
1
Abrir archivos;
Total extranjero = 0;
WHILE (haya reg. ventas) y
El diseo de casos
de prueba tiene
que estar basado
en la eleccin de
caminos
importantes que
ofrezcan una
seguridad
aceptable
(mismo producto)
IF (nacional) THEN
Sumar venta nacional a total nacional
ELSE
Sumar venta extranjero a total extranjero
ENDIF;
7a
7b
8,9
10,11
Cerrar archivos.
12,13
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.
PRUEBAS ESTRUCTURALES
GRAFO DE FLUJO DE LAS ESTRUCTURAS BASICAS DE PROGRAMA
Secuencia
Si x entonces...
(If x then...else...)
Consejos:
Hacer... hasta x
(Do...until x)
Repetir
Mientras x hacer...
(While x do...)
Menos riguroso
PRUEBAS ESTRUCTURALES
(ms barato)
Ms riguroso
(ms caros)
PRUEBAS ESTRUCTURALES
EJEMPLO DE DESCOMPOSICION DE UNA
DECISION MULTICONDICIONAL
then
(a=1) and (c=4)
else
then
(a=1)
(c=4)
else
PRUEBAS ESTRUCTURALES
LA COMPLEJIDAD DE McCABE V(G) (COMPLEJIDAD CICLOMTICA)
La complejidad de
McCabe se puede
calcular de
cualquiera de estas 3
formas
PRUEBAS ESTRUCTURALES
LA COMPLEJIDAD DE McCABE V(G)
a)
b)
c)
a11
a10
a8
11
10
Regin 4
a13
a5
a4
a14
a12
Regin 3
a7
Regin 1
a3
V(G) = 14-11+2 = 5
V(G) = 5 regiones cerradas
V(G) = 5 condiciones
Regin 5
a9
Regin 2
a6
a2
a1
12.170
PRUEBAS ESTRUCTURALES
PRUEBAS FUNCIONALES
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:
PRUEBAS FUNCIONALES
PRUEBAS FUNCIONALES
PARTICIPACIONES O CLASES DE EQUIVALENCIA
PASOS PARA IDENTIFICAR CLASES DE EQUIVALENCIA
1.
2.
3.
PRUEBAS FUNCIONALES
PARTICIPACIONES O CLASES DE EQUIVALENCIA
PASOS PARA IDENTIFICAR CLASES DE EQUIVALENCIA
PRUEBAS FUNCIONALES
PARTICIPACIONES O CLASES DE EQUIVALENCIA
PASOS PARA IDENTIFICAR CASOS DE PRUEBA
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:
PRUEBAS FUNCIONALES
TABLA DE CLASES DE EQUIVALENCIA DEL EJEMPLO
Ejemplo: Aplicacin bancaria en la que el operador debe proporcionar un cdigo, un
nombre y una operacin
Condicin de entrada
Cdigo rea
Clases vlidas
(1) 200 cdigo 999
N de 3 dgitos que no
empieza con 0 ni 1)
cheque
depsito
pago factura
Clases invlidas
(2) cdigo <200
(3) cdigo >999
(4) no es nmero
(6) menos de 6 caracteres
(7) ms de 6 caracteres
(12) ninguna orden vlida
retirada de fondos
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
PRUEBAS FUNCIONALES
TCNICA: ANALISIS DE VALORES LIMITE (AVL)
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:
PRUEBAS FUNCIONALES
ANALISIS DE VALORES LIMITE (AVL)
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
PRUEBAS FUNCIONALES
TCNICA: CONJETURA DE ERRORES
Se enumera una lista de posibles equivocaciones tpicas que pueden cometer los
desarrolladores y de situaciones propensas a ciertos errores
El valor cero es una situacin propensa a error tanto en la salida como
en la entrada
En 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
Es recomendable imaginar que el programador pudiera haber interpretado
algo mal en la especificacin
Tambin interesa imaginar lo que el usuario puede introducir como entrada
a un programa
...
PRUEBAS ALEATORIAS
Una cuestin importante es por qu son necesarias las pruebas de caja blanca
si comprobamos que las funciones se realizan correctamente?
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
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
No detecta el error lgico, que si sera detectado con otro tipo de pruebas funcionales.
Plan de
Pruebas
...............
Especificacin
de caso de
prueba
Especificacin
de procedimiento
de pruebas
EJECUCIN
Informes
Especificacin
de diseo
de las 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
PLAN DE PRUEBAS
Estructura fijada en el estndar
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
ESPECIFICACION DE PROCEDIMIENTO
DE PRUEBA
Objetivo del documento
ESPECIFICACION DE PROCEDIMIENTO
DE PRUEBA
Estructura fijada en el estndar
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:
1.EJECUTAR
3.PRUEBAS
ADICIONALES
2.COMPROBAR
SI TERMIN
LA PRUEBA
3.EVALUAR
RESULTADOS
DEPURACIN DEL
CDIGO
Si
DEFECTOS
EN LAS
PRUEBAS
ALGUN
FALLO?
No
COMPROBAR
TERMINACIN
Si
DEFECTOS
SOFTWARE
No
CONDICIONES
ANORMALES
EJECUCIN
Si
Pruebas
adicionales?
No
EVALUACIN
TERMINACIN
ANORMAL
Criterios de
complecin descritos
en el plan de pruebas
TERMINACIN
NORMAL
EJECUCION
Histrico
de
pruebas
Informe
de
incidente
Ejecucin
Histrico
de
pruebas
Informe
de
incidente
Ejecucin
Informe
Resmen
Se pueden
distinguir
histricos,
incidencias y
resmenes
HISTORICO DE PRUEBAS
Objetivo
El histrico de pruebas (test log) documenta
todos los hechos relevantes ocurridos durante
la ejecucin de las pruebas
HISTORICO DE PRUEBAS
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
INFORME DE INCIDENTE
Objetivo:
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.
INFORME DE INCIDENTE
Estructura fijada en el estndar:
Identificador
Resumen del incidente
Descripcin de datos objetivos (fecha/hora, entradas,
resultados esperados, etc)
Impacto que tendr sobre las pruebas
Objetivo:
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.500
Ejecucin
Causas
ignoradas
Correcciones
Depuracin
Causas
Sntomas
de
defectos
(errores)
12.510
NO)
12.520
12.530
12.535
12.540
Con el esquema del diseo del software, los mdulos probados se integran
para comprobar sus interfaces en el trabajo conjunto (prueba de integracin)
El 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).
El 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)
Por 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)
Pruebas de
aceptacin
Especificac.
de requisitos
Pruebas de
sistema
Diseo
modular
Pruebas de
integracin
Especific. y
lgica de
mdulo
Pruebas de
unidad
Cdigo
PRUEBA DE UNIDAD
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)
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
PRUEBAS DE INTEGRACION
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
PRUEBAS DE INTEGRACION
Tipos fundamentales de integracin
1 fase
Impulsor de E
Impulsor de F
Impulsor de G
Impulsor de D
Pruebas de
Unidad
3 fase
Impulsor de F
Prueba de unidad de E
Prueba de integracin de B con E
ETAPAS FUNDAMENTALES DE LA
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
MDULOS FICTICIOS
La creacin de mdulos ficticios subordinados es ms complicada que
la creacin de impulsores
-Complejidad
+Complejidad
Tipo 1
Tipo 2
Tipo 3
Muestra
Muestra
Devuelve
mensaje
param. de entrada
valor
Tipo 4
Recibe y
devuelve valor
Ficticio C
Ficticio D
E
Recordar el recorrido de
rboles en profundidad
Ficticio E
ficticio D
Recordar el recorrido de
rboles en anchura
INTEGRACION NO INCREMENTAL
Cada mdulo que tiene que ser probado necesita lo siguiente:
Casos de
prueba
ficticio 1
Mdulo que se
va a probar
ficticio 2
Resultados
ficticio 3
Ascendente
Ventajas
Es un mtodo ventajoso si aparecen
Desventajas
Se requieren mdulos impulsores, que
deben codificarse.
El programa, como entidad, slo
aparece cuando se agrega el ltimo
mdulo.
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 ficticios que
suelen ser complejos de crear.
PRUEBA DE ACEPTACION
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