Académique Documents
Professionnel Documents
Culture Documents
Ciclo de vida
software
Activid.
1
Activid.
2 …......... Activ.
N-1
Pruebas
….........
Controles
DEFINICIONES
Pruebas (test): «una actividad en la cual un sistema o uno de sus
componentes se ejecuta en circunstancias previamente
Proceso de
ejecutar un
especificadas, los resultados se observan y registran y se realiza
programa una evaluación de algún aspecto»
con el fin de
encontrar
errores
Caso de prueba (test case): «un conjunto de entradas, condiciones
de ejecución y resultados esperados desarrollados para un objetivo
particular»
DEFINICIONES
Defecto Un defecto
Fallo Un resultado incorrecto
Error Una acción humana que conduce a un resultado incorrecto .
PRUEBAS DEL SOFTWARE
12.040
Defecto (calidad)
S.Aproximación
¡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 debería) criticidad del sistema)
PRUEBAS DEL SOFTWARE
12.045
Las pruebas son una tarea tanto o más creativa que el desarrollo de
software. Siempre se han considerado las pruebas como una tarea
destructiva y rutinaria.
PROCESO DE PRUEBA
ACTIVIDADES
Entrada Salida
Estructural
Caja negra
Funciones
PRUEBAS DEL SOFTWARE
12.120
PRUEBAS ESTRUCTURALES
GRAFO DE FLUJO DE UN PROGRAMA (PSEUDOCODIGO)
1
Abrir archivos;
Leer archivo ventas, al final indicar no más registros; 2
Limpiar línea de impresión;
WHILE (haya registros ventas) DO
3
Total nacional = 0;
Total extranjero = 0; 4
WHILE (haya reg. ventas) y (mismo producto)
IF (nacional) THEN 5
El diseño de casos Sumar venta nacional a total nacional
de prueba tiene ELSE 6
que estar basado Sumar venta extranjero a total extranjero
en la elección de ENDIF; 7a 7b
caminos Leer archivo ventas, al final indicar no más registros;
PRUEBAS ESTRUCTURALES
GRAFO DE FLUJO DE LAS ESTRUCTURAS BASICAS DE PROGRAMA
x x
Más riguroso
(más caros)
PRUEBAS DEL SOFTWARE
12.150
PRUEBAS ESTRUCTURALES
then then
(a=1) (c=4)
(a=1) and (c=4)
else
else
PRUEBAS DEL SOFTWARE
12.160
PRUEBAS ESTRUCTURALES
PRUEBAS ESTRUCTURALES
a1
a2 a3
12.170
a4
3 Región 1
a5
a6 a7
4
Región 2
a8
a9
5 Región 3
a10
6
a11 a12
Región 4
7 8
a13
a14
PRUEBAS DEL SOFTWARE
9
PRUEBAS ESTRUCTURALES
10
Región 5
11
CALCULO DE LA COMPLEJIDAD CICLOMATICA SOBRE UN GRAFO
a) V(G) = 14-11+2 = 5
b) V(G) = 5 regiones cerradas
c) V(G) = 5 condiciones
PRUEBAS DEL SOFTWARE
12.180
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
PRUEBAS FUNCIONALES
TÉCNICA: PARTICIPACIONES O CLASES DE EQUIVALENCIA
Cualidades que definen un
PRUEBAS FUNCIONALES
PARTICIPACIONES O CLASES DE EQUIVALENCIA
PRUEBAS FUNCIONALES
PARTICIPACIONES O CLASES DE EQUIVALENCIA
PRUEBAS FUNCIONALES
PARTICIPACIONES O CLASES DE EQUIVALENCIA
El último paso del método 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
Habría que diseñar casos de prueba que cubran todas las clases de equivalencia, tanto
válidas como inválidas, y para las inválidas en casos de prueba distintos
PRUEBAS DEL SOFTWARE
12.240
PRUEBAS FUNCIONALES
TÉCNICA: ANALISIS DE VALORES LIMITE (AVL)
• La experiencia indica que los casos de prueba que exploran las condiciones
límite de un programa producen un mejor resultado para detectar defectos
• El AVL es una técnica de diseño 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 condición de entrada especifica un rango de valores, se deben generar
casos para los extremos del rango y casos no válidos para situaciones justo más
allá de los extremos
2. Si la condición de entrada especifica un número finito y consecutivo de valores, hay que
escribir casos para los números máximo, mínimo, uno más del máximo y uno menos del
mínimo de valores
3. Usar la regla 1 para la condición de salida
4. Usar la regla 2 para cada condición de salida
PRUEBAS FUNCIONALES
TÉCNICA: CONJETURA DE ERRORES
Se enumera una lista de posibles equivocaciones típicas que pueden cometer los
desarrolladores y de situaciones propensas a ciertos errores
PRUEBAS ALEATORIAS
Una cuestión importante es ¿por qué son necesarias las pruebas de caja blanca
si comprobamos que las funciones se realizan correctamente?
Especificación Especificación
de diseño de diseño
de las pruebas ............... de las pruebas
Especificación
de caso de
prueba
Especificación
de procedimiento
de pruebas
EJECUCIÓN
Informes
PRUEBAS DEL SOFTWARE
12.320
PLAN DE PRUEBAS
PLAN DE PRUEBAS
Estructura fijada en el estándar
1. Identificador único del documento
2. Introducción y resumen de elementos y características a probar
3. Elementos software a probar
4. Características a probar
5. Características que no se probarán
6. Enfoque general de la prueba
7. Criterios de paso/fallo para cada elemento
8. Criterios de suspensión y requisitos de reanudación
9. Documentos a entregar
10. Actividades de preparación y ejecución de pruebas
11. Necesidades de entorno
12. Responsabilidades en la organización y realización de las pruebas
13. Necesidades de personal y formación
14. Esquema de tiempos
15. Riesgos asumidos por el plan y planes de contingencias
16. Aprobaciones y firmas con nombre y puesto desempeñado
PRUEBAS DEL SOFTWARE
12.340
identificador
casos que se van a utilizar
procedimientos que se van a seguir
ESPECIFICACION DE PROCEDIMIENTO
DE PRUEBA
ESPECIFICACION DE PROCEDIMIENTO
DE PRUEBA
Estructura fijada en el estándar
1.EJECUTAR
3.PRUEBAS
ADICIONALES
2.COMPROBAR
SI TERMINÓ
LA PRUEBA
3.EVALUAR
RESULTADOS
PRUEBAS DEL SOFTWARE
12.410
EJECUTAR
PRUEBAS
DEPURAR
LAS DEPURACIÓN DEL
PRUEBAS CÓDIGO
Si ¿ALGUN Si
FALLO? DEFECTOS
DEFECTOS
EN LAS SOFTWARE
No
PRUEBAS
COMPROBAR
TERMINACIÓN
PRUEBAS DEL SOFTWARE
12.420
PRUEBAS
ADICIONALES EJECUCIÓN
No Si Criterios de
CONDICIONES ¿Pruebas compleción descritos
ANORMALES adicionales? en el plan de pruebas
No
TERMINACIÓN
NORMAL
EVALUACIÓN
TERMINACIÓN
ANORMAL
PRUEBAS DEL SOFTWARE
12.430
EJECUCION
Se pueden
distinguir
históricos,
Histórico Informe Histórico Informe
de de de de incidencias y
pruebas incidente pruebas incidente
resúmenes
Ejecución
Ejecución
Informe
Resúmen
PRUEBAS DEL SOFTWARE
12.440
HISTORICO DE PRUEBAS
Objetivo
HISTORICO DE PRUEBAS
Identificador
Fecha y hora
Identificador de informe de incidente
Otras informaciones
PRUEBAS DEL SOFTWARE
12.460
INFORME DE INCIDENTE
Objetivo:
INFORME DE INCIDENTE
Identificador
Objetivo:
Identificador
Casos
de
prueba
Ejecución
Causas
ignoradas
Correcciones
Síntomas
de
Depuración defectos
Causas (errores)
Esta información no debería ser usada para evaluar al personal, sino para la
formación del mismo sobre cómo prevenir los errores. También se utiliza para
predecir futuros fallos software
PRUEBAS DEL SOFTWARE
12.535
Con el esquema del diseño del software, los módulos probados se integran
para comprobar sus interfaces en el trabajo conjunto (prueba de integración)
Etapas típicas más en detalle
El software ya validado se integra con el resto del sistema (por ejemplo, elementos
mecánicos, interfaces electrónicas, etc.) para probar su funcionamiento conjunto
(prueba del sistema)
Por último, el producto final se pasa a la prueba de aceptación para que el usuario
compruebe en su propio entorno de explotación si lo acepta como está o no (prueba
de aceptación)
PRUEBAS DEL SOFTWARE
12.550
Código
PRUEBA DE UNIDAD
Se trata de las pruebas formales que permiten declarar que un módulo está listo y
terminado (no las informales que se realizan mientras se desarrollan los módulos)
PRUEBAS DE INTEGRACION
PRUEBAS DE INTEGRACION
Tipos fundamentales de integración
Se combinan los módulos de bajo nivel en grupos que realicen una función
o subfunción específica (o quizás si no es necesario, individualmente) de
este modo reducimos el número de pasos de integración.
Se escribe para cada grupo un módulo impulsor o conductor de este
modo permitimos simular la llamada a los módulos, introducir datos de
prueba y recoger resultados.
Se prueba cada grupo mediante su impulsor
Se eliminan los módulos impulsores y se sustituyen por los módulos de
nivel superior en la jerarquía.
PRUEBAS DEL SOFTWARE
12.590
B C D
E F G
PRUEBAS DEL SOFTWARE
12.600
E F G D
Pruebas de
Unidad
PRUEBAS DEL SOFTWARE
12.610
2ª fase 3ª fase
Impulsor de E Impulsor de F A
B C D
B C
E F G
E F G
Prueba de unidad de E
Prueba de integración de B con E
PRUEBAS DEL SOFTWARE
12.615
ETAPAS FUNDAMENTALES DE LA
INTEGRACION DESCENDENTE
El módulo raíz es el primero: Se escriben módulos ficticios que simulan
los subordinados
MÓDULOS FICTICIOS
-Complejidad
Módulos que sólo muestran un mensaje de traza
B Ficticio C Ficticio D
Recordar el recorrido de
árboles en profundidad
PRUEBAS DEL SOFTWARE
12.660
B C ficticio D
Recordar el recorrido de
Ficticio E árboles en anchura
PRUEBAS DEL SOFTWARE
12.670
INTEGRACION NO INCREMENTAL
Cada módulo que tiene que ser probado necesita lo siguiente:
Una vez probado cada módulo por separado, se ensamblan todos de una vez y
se prueban en conjunto
PRUEBAS DEL SOFTWARE
12.680
Impulsor
Ventajas de la incremental:
PRUEBA DE ACEPTACION
Es la prueba planificada y organizada formalmente para
determinar si se cumplen los requisitos de aceptación marcados
por el cliente.
Sus características principales son las siguientes:
RECOMENDACIONES GENERALES