GC Pruebas

Gestin de Calidad en Direccin
de Proyectos
Las pruebas.
Jos Luis Fernndez Snchez
U.D. proyectos-INGOR-ETSII
Objetivo de la asignatura
El objetivo principal es proporcional al
alumno las mejores tcnicas y prcticas
para gestionar la calidad a nivel de un
proyecto,
a diferencia de los sistemas de gestin
de calidad que se aplican a nivel de una
empresa u organizacin
Noviembre 2016
Contenido de la asignatura
1.
2.
3.
4.
5.
Introduccin. Los procesos de gestin de la

calidad segn el PMBoK del PMI
Sistema de gestin de la calidad
Herramientas y tcnicas
Las pruebas
Plan de calidad del proyecto. Auditorias de
calidad.
Noviembre 2016
Objetivo de la integracin y pruebas

de un sistema
Independientemente de la metodologa
de desarrollo utilizada para un producto
o servicio (sistema), se debe de definir:
Como el producto o servicio va a ser
integrado en su forma final
Como el producto o servicio va a ser
verificado para garantizar el cumplimiento
de los requisitos
Noviembre 2016
Subprocesos de la Integracin y
Verificacin de un Sistema
Los subprocesos que conforman la
Integracin y Verificacin de un Sistema
son:
Planificacin
Definicin
Ejecucin
Noviembre 2016
Contexto de la I y V del Sistema

Plan de Gestin de la Ingeniera de S.
I y V del
Sistema
Requisitos del Usuario
Especificaciones y documentos de diseo

Plan Desarrollo
Software
Diseo
Produccin
Y
Despliegue
Planificacin
Definicin
Ejecucin
Plan de Integracin
Y Verificacin
Sistema Integrado
Producto
Sistema desplegado
Paquete de diseo del sistema
Noviembre 2016
Planificacin de la integracin y
pruebas de un sistema
Este subproceso consiste en la formulacin de
planes diversos:
Cualificacin del sistema
Cualificacin de preproduccin
Aceptacin del producto
Cualificacin previa al despliegue
Aceptacin en la ubicacin final
Cada plan definir el entorno a utilizar, las

tcnicas de verificacin a utilizar y los
procedimientos a seguir
Noviembre 2016
Planificacin de la integracin y
pruebas de un sistema
Las principales tareas de este subproceso sern:
1.
Analizar los requisitos del usuario y los planes de proyecto
2.
Desarrollar las matrices de trazabilidad de los requisitos
3.
Definir los requisitos de integracin (listas de los
componentes predecesores necesarios)
4.
Desarrollar la estrategia de I y V
5.
Definir los requisitos de verificacin
6.
Definir las instalaciones necesarias
7.
Definir las necesidades de recursos humanos
8.
Definir los datos necesarios
9.
Definir las necesidades de equipos hw/sw
10.
Preparar el plan de integracin y verificacin
Noviembre 2016
Definicin de la integracin y pruebas

de un sistema
Este subproceso consiste en:
1.
Definir las tcnicas concretas de verificacin
de los requisitos funcionales y requisitos de
prestaciones
2.
Definir y establecer el entorno de
integracin y verificacin
3.
Definir procedimientos detallados para cada
actividad de verificacin
4.
Documentar la informacin y obtener la
aprobacin del Cliente del plan
Noviembre 2016
Definicin de la integracin y pruebas

de un sistema
Las principales tareas de este subproceso son:
1.
Definir los requisitos de los operadores e instalaciones de pruebas
2.
Desarrollar los planes de integracin
3.
Desarrollar los planes de verificacin
4.
Desarrollar los procedimientos de integracin y ensamblaje del
sistema
5.
Disear el equipo de integracin, instalaciones y datos de simulacin
y escenarios
6.
Disear el equipo de verificacin, instalaciones y datos de simulacin
y escenarios
7.
Desarrollar los procedimientos de verificacin
8.
Desarrollar los datos de integracin
9.
Construir/Modificar las instalaciones y equipamiento de verificacin
10.
Certificar el equipamiento de integracin, las instalaciones y los
datos
11.
Certificar el equipamiento de verificacin, las instalaciones y los
datos
Noviembre 2016
10
Ejecucin de la integracin y pruebas

de un sistema
El objetivo principal de cada prueba de una
etapa en la integracin es asegurar que el
producto integrado cumple sin errores con
las funcionalidades requeridas.
Para ello:
La integracin se focaliza en identificar y
eliminar defectos del producto
La verificacin demuestra al cliente que el
producto es aceptable para el (cumple sus
requisitos)
Noviembre 2016
11
Ejecucin de la integracin y pruebas

de un sistema
Las principales tareas son:
1.
Verificar el cumplimiento de los requisitos por inspeccin
2.
Verificar el cumplimiento de requisitos por tcnicas de anlisis
3.
Comprobar la idoneidad de los procesos de operacin del sistema
4.
Comprobar la idoneidad de las instalaciones y operadores
5.
Realizar pruebas de idoneidad del producto antes de la integracin
6.
Realizar el ensamblado incremental y comprobacin de los
subsistemas
7.
Realizar una comprobacin de la idoneidad para comenzar las
pruebas formales/demostracin
8.
Verificar por pruebas formales/demostracin la aceptacin del
producto
9.
Revisar los fallos Pruebas/Demostracin
10.
Realizar un anlisis de modos de fallo
11.
Realizar una revisin de las pruebas de aceptacin
12.
Realizar una auditoria de la configuracin funcional y/o una auditoria
de la configuracin fsica
Noviembre 2016
12
Desarrollo
Subproceso de a ejecucin de I y V
Tarea 3
Tarea 4
Tarea 5
Tarea 1
Tarea 2
Bucle
de
Integracin
Tarea 6
item falla
Tarea 7
item pasa
Sistema pasa
item pasa
Tarea 11
Tarea 10
Rediseo
Tarea 8
Tarea 9
Tarea 12
Sistema integrado y cualificado
Noviembre 2016
13
Concepto de pruebas del software

Prueba es el proceso de ejecutar un programa con el
fin de encontrar errores (Myers).
Prueba es el ejercicio controlado de un cdigo para
exponer errores (Deutsch).
Prueba es un proceso de inferencia de las
propiedades de conducta de un programa basadas en
la ejecucin del programa en un entorno conocido y
con entradas seleccionadas (Goodenough).
Noviembre 2016
14
Niveles de pruebas (IEEE Std. 1059)

Nivel Prueba
Definicin en el
Estndar
Propsito
Trazabilidad
Pruebas unitarias
Pruebas realizadas para

verificar la implementacin
de un nico elemento
software (ej. unidad,
modulo) o una coleccin de
elementos software.
Garantiza que la lgica

del programa est
completa y es correcta.
Garantiza que la
componente trabaja tal
como se dise.
De cada prueba al
diseo detallado.
Pruebas de integracin
Una progresin ordenada de

pruebas en las que los
elementos software,
hardware o ambos se
combinan y prueban hasta
que el sistema completo
haya sido integrado.
Garantiza que los

objetivos de diseo se
cumplen
De cada prueba al
diseo de alto nivel.
Pruebas de sistema
El proceso de pruebas de un
sistema integrado hardware
y software para verificar el
cumplimiento de los
requisitos
Garantiza que el software

como entidad completa
cumple os requisitos
De cada prueba a los

requisitos
Pruebas de aceptacin
Pruebas realizadas para

determinar si un sistema
satisface sus criterios de
aceptacin y capacitar al
cliente determinar si acepta
o no el sistema
Garantiza que los

requisitos del cliente se
cumplen y todos los
componentes estn
incluidos en el entregable
del cliente.
De cada prueba a los

requisitos especficos
del cliente.
Noviembre 2016
15
Las pruebas en el ciclo de vida del

software (IEEE Std. 1012)
Fases del proyecto

Requisitos
Diseo
Implementacin
Pruebas
Instalacin
Pruebas unitarias
Pruebas del sistema
Noviembre 2016
16
Es el proceso de comparar el software con sus
requisitos iniciales y con las necesidades actuales del
usuario.
Estas pruebas se realizan por el usuario final del
software para determinar si lo acepta o no.
Se utiliza el entorno operacional.
La base para la realizacin de estas pruebas son los
requisitos y manuales de usuario.
Las pruebas de aceptacin empiezan muy temprano
en el ciclo de vida del software por ejemplo, cuando
la primera versin de la documentacin del usuario
es producida en la fase de requisitos.
Noviembre 2016
17
Pruebas del sistema (I)

Es el proceso de probar un sistema integrado
por hardware y software para comprobar que
el sistema cumple con los requisitos
especificados.
Si el producto es un programa se puede
tambin aplicar esta prueba.
Los Requisitos del Sistema han de ser
medibles o comprobables.
No se puede usar los requisitos de usuario
como base de la prueba.
Noviembre 2016
18
Pruebas del sistema (II)- Tipos

Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
funcionales
de volumen
de esfuerzo
de factores humanos
de seguridad
de comportamiento
de almacenamiento
de configuracin
de facilidad de instalacin
de compatibilidad/conversin
de fiabilidad
de recuperacin
de capacidad de servicio de mantenimiento
de documentacin
de procedimientos
Noviembre 2016
19
Pruebas funcionales
Estas pruebas tratan de encontrar discrepancias entre el
sistema y sus requisitos funcionales.
Los requisitos funcionales conllevan una descripcin precisa del
comportamiento del sistema desde el punto de vista del mundo
exterior.
Las pruebas funcionales salvo cuando se usa en programas de
tamao reducido son normalmente de tipo caja negra.
A fin de realizar una prueba de funcin se analizan los requisitos
para obtener un conjunto de casos de prueba.
Para las pruebas de funcionales son especialmente tiles las
tcnicas de particin de equivalencia, el anlisis de valor lmite,
los grafos causa-efecto y el mtodo de conjetura de errores que
se ven posteriormente.
Noviembre 2016
20
Aproximaciones descendente y
ascendente
Es la realizacin ordenada y progresiva de pruebas en las que
se combinan componentes software o hardware y se prueban
hasta que el sistema total ha sido integrado.
Para la realizacin del proceso de pruebas se ha de tener en
cuenta:
La preparacin de un conjunto de casos de prueba.
La manera segn la cual se combinan los distintos mdulos. Esto
conlleva a la seleccin de una metodologa de pruebas
descendente ascendente u otra aproximacin por ejemplo al
orientada a estimulo-respuesta.
Se podra pensar en una realizacin de pruebas no incremental,

probando el programa completo (big bang) lo que no es
recomendable
Noviembre 2016
22
Pruebas de integracin descendentes

La estrategia descendente comienza con el mdulo superior o
inicial del programa. Despus de esto no existe ningn
procedimiento correcto para seleccionar el prximo mdulo que
ha de probarse. La nica regla es que para que un mdulo
pueda convertirse en el siguiente mdulo es necesario que
previamente se haya probado por lo menos uno de los mdulos
correspondientes al mdulo superior.
Si hay componentes crticas del programa se deben proyectar
las pruebas de tal modo que estas componentes sean
agregadas lo antes posible.
Se deben proyectar las pruebas de tal modo que los mdulos de
entrada/salida se incorporen a la prueba lo ms pronto posible.
Se utilizarn stubs (modulo auxiliar): retorna al llamador
inmediata-mente, salida constante, salida aleatoria o funcin
primitiva de la funcin final.
Noviembre 2016
23
descendentes- Ejemplo
Arquitectura del sistema
Main
A1
Noviembre 2016
A2
C1
C2
24

Ejemplo Paso 1
Main
Lo mdulos representados como crculos son stubs o mdulos auxiliares
Noviembre 2016
25

Ejemplo Paso 2
Main
A1
A2
C1
C2

Noviembre 2016
26

Ejemplo Paso 3
Main
A1
A2
C1
C2

Noviembre 2016
27
descendentes- Ejemplo Paso 4
Main
A1
Noviembre 2016
A2
C1
C2
28
Pruebas ascendentes
La estrategia ascendente comienza con los mdulos terminales
del programa (aquellos que no llamen a otros). Despus que
estos mdulos han sido probados, no existe el mejor
procedimiento para seleccionar el mdulo siguiente a ser
probado. La nica regla es que para ser elegido como mdulo
siguiente, todos los mdulos subordinados deben haber sido
probados previamente.
Si hay componentes crticas en el programa se deben proyectar
las pruebas de tal modo que estas componentes sean
agregadas lo antes posible.
Se requiere la utilizacin de drivers (conductores): toman el
lugar de los mdulos del nivel ms alto, llaman al mdulo o
conjunto de mdulos en prueba, suministran entradas y otros
estmulos, registran salidas y comportamiento.
Noviembre 2016
29
Pruebas de integracin ascendentesEjemplo

Arquitectura del sistema
Main
A1
Noviembre 2016
A2
C1
C2
30
Pruebas de integracin ascendentesEjemplo Paso 1
Noviembre 2016
31
A2
C1
A2
Noviembre 2016
C1
32
A1
Noviembre 2016
A2
C1
C2
33

Main
A1
Noviembre 2016
A2
C1
C2
34
Comparacin pruebas integracin

descendentes y ascendentes
Descendentes
Ascendentes
Son ventajosas si hay fallos en la parte

superior
Son ventajosas si hay fallos en la parte

inferior
Una vez incorporadas las funcionalidades

de E/S es ms fcil
Las condiciones de prueba son ms

fciles de crear
Las condiciones de prueba pueden ser

muy difciles
Es ms fcil la observacin de los

resultados de la prueba
La observacin de salida de la prueba es

ms difcil
Los drivers son ms complicados que los

stubs
Los mdulos auxiliares son mas sencillos

que los drivers
El sistema como entidad no existe hasta

que se ha agregado el ltimo mdulo
Noviembre 2016
35
Pruebas unitarias de caja

blanca
Tambin llamadas pruebas de
cobertura lgica
Pruebas unitarias de caja blanca

Las pruebas de caja blanca (tambin conocidas como pruebas de caja de
cristal o pruebas de cobertura lgica) se centran en los detalles internos del
software, por lo que su diseo est fuertemente ligado al cdigo fuente. El
responsable de la prueba escoge distintos valores de entrada para examinar
cada uno de los posibles flujos de ejecucin del programa y cerciorarse de que
se devuelven los valores de salida adecuados.
Aunque las pruebas de caja blanca son aplicables a varios niveles, unidad,
integracin o sistema, habitualmente se aplican a las unidades de software. Su
cometido es comprobar los flujos de ejecucin dentro de cada unidad (funcin,
mtodo de clase, mdulo, etc.) pero tambin pueden probar los flujos entre
unidades durante la integracin, e incluso entre subsistemas, durante las
pruebas de sistema
los criterios que vamos a utilizar para disear estos casos de prueba son:
Cobertura
Cobertura
Cobertura
Cobertura
Cobertura
de
de
de
de
de
sentencias.
decisiones.
condiciones.
decisiones/condiciones.
condicin mltiple.
Noviembre 2016
37
Pruebas unitarias de caja blanca. Cobertura

de decisin-Tcnica de pruebas
estructuradas (1)
Esta tcnica se basa en el uso de la mtrica
de complejidad ciclomtica de Mc Cabe.
Esta mtrica basada en la teora de grafos,
nos mide el nmero de caminos
independientes en un componente software
unitario.
La experiencia indica que en un mdulo de
tamao apropiado, la complejidad ciclomtica
no debera ser superior a 10
Noviembre 2016
38
Pruebas unitarias de caja blanca.

Cobertura de decisin-Tcnica de pruebas
estructuradas (2)
Clculo complejidad ciclomtica. Se puede
calcular de varias formas:
Siendo: N= Nmero de nodos, E= Nmero de flujos,
SN= Nmero de nodos con ms de un flujo de
salida y RG= Nmero de regiones cerradas
(habiendo cerrado el grafo con una unin fin
principio)
C = E- N +1
C= SN +1
C= RG
Noviembre 2016
39

estructuradas (3)
C= 1
C= 2
C= 5
Noviembre 2016
40

estructuradas (4)
Procedimiento de diseo de los casos de prueba:
1.
Se elige un camino de referencia, normalmente ser el ms
largo
2.
El siguiente camino se elige localizando la primera decisin en
el camino de referencia y utilizando otra salida distinta a la
utilizada pero manteniendo a sus vez las otras decisiones
3.
Se hace lo mismo para las siguientes decisiones, tomando
una salida distinta a la de referencia y manteniendo si es
posible las salidas de las otras decisiones
4.
Pueden utilizarse otros mtodos para encontrar un conjunto
de caminos independientes. Los bucles se tratan de modo
similar a las decisiones.
5.
Los casos de prueba de excepciones sern independientes
Noviembre 2016
41
Pruebas de caja negra

Conociendo una funcin especfica para la que fue diseado
el componente, se pueden disear pruebas que demuestren
que dicha funcin est bien realizada. Dichas pruebas son
llevadas a cabo sobre la interfaz del software, es decir, de la
funcin, actuando sobre ella como una caja negra,
proporcionando unas entradas y estudiando las salidas para
ver si son o no las esperadas.
Pruebas de caja negra

Conociendo una funcin especfica para la que fue
diseado el sistema, subsistema o componente, se
pueden disear pruebas que demuestren que dicha
funcin est bien realizada. Dichas pruebas son
llevadas a cabo sobre la interfaz del software, es
decir, de la funcin, actuando sobre ella como una
caja negra, proporcionando unas entradas y
estudiando las salidas para ver si son o no las
esperadas.
Las tcnicas son: particiones de equivalencia, anlisis
de valores lmite , conjetura de errores y pruebas
basadas en el uso de tablas de decisin.
Noviembre 2016
43
Pruebas basadas en el uso de

tablas de decisin. Grafos causaefecto
Tcnica til si la especificacin
contiene combinaciones de
condiciones de entrada.
Grafos causa-efecto
Los grafos causa-efecto constituyen una tcnica que ayuda de
una manera sistemtica en la seleccin de un conjunto
productivo de casos de prueba.
Esta tcnica explora las entradas y combinaciones de
condiciones de entrada para desarrollar los casos de prueba.
Las entradas y salidas de un programa se determinan a travs
del anlisis de las especificaciones de requisitos. Estas
especificaciones de requisitos son traducidas a una red o grafo
booleano que se utiliza para obtener los casos de prueba.
Esta tcnica sirve tambin para encontrar ambigedades en las
especificaciones. Sin embargo no produce todos los casos de
prueba tiles ni explora adecuadamente las condiciones lmite.
Noviembre 2016
45
Grafos causa-efecto. Notacin (1)

A
IF A THEN B
B
IF NOT A THEN B
C
IF A OR B OR C THEN D
Noviembre 2016
IF A AND B THEN C
46
Grafos causa-efecto. Notacin

Restricciones (2)
a
b
Exclusivo
Inclusivo
a
O
R
b
Uno y solo uno
Noviembre 2016
M
b
Requiere
b
Mscara
47
Grafos causa-efecto. Pasos a

realizar
1.
2.
3.
4.
5.
6.
7.
Identificar todos los requisitos del sistema y dividir-los en entidades

identificables.
Examinar los requisitos para identificar las causas y efectos. Una
causa es una entrada; un efecto es una condicin de salida o una
transformacin del sistema.
Asignar a cada causa y efecto un nico nmero.
El contenido semntico de la especificacin es analizado y
transformado en un grafo booleano que une causas y efectos.
Se marca el grafo con vnculos que describen combinacio-nes de
causas y/o efectos imposibles por causa de relaciones sintcticas o
del entorno.
Por medio de un trazado metdico de condiciones de estado sobre
el grafo, ste es convertido en una tabla de decisin de entrada
limitada. Cada columna de la tabla representa un caso de prueba.
Las columnas de la tabla de decisin son convertidas en casos de
prueba.
Noviembre 2016
48
Grafos causa-efecto. Ejemplo (1)

Un sistema de gestin de base de datos requiere que cada fichero en
la base de datos tenga su nombre listado en un ndice maestro que
indica la localizacin de cada fichero. En ndice se divide en 10
secciones. Se desarrolla un sistema para permitir al usuario introducir
un comando interactivamente para mostrar cualquier seccin del ndice
en su terminal.
La especificacin del sistema es como sigue: Mostrar en pantalla una
de las 10 posibles secciones; se teclearan comandos que constan de
una letra y un dgito. El primer carcter a introducir ser una D (para
display) o una L (para listar) y deber estar en la columna 1. El
segundo carcter ser un dgito de 0-9 en la columna 2. Si existe un
comando se mostrar la seccin identificada por el dgito. Si el primer
carcter es incorrecto se imprimir el mensaje de error A. Si el segundo
carcter es incorrecto se imprimir el mensaje de error B.
A : COMANDO NO VALIDO
B : NUMERO DE INDICE NO VALIDO
Noviembre 2016
49

Identificacin de causas y efectos:
Causas
1. Carcter D en columna 1
2. Carcter L en columna 1
3. Carcter en columna 2 es un dgito
Efectos
50. Se muestra la seccin del ndice
51. Se muestra mensaje de error A
52. Se muestra mensaje de error B
Noviembre 2016
50

Construccin grafo:
1
51
20
E
50
Noviembre 2016
52
51

Construccin tabla:
Causas
1
2
3
Efectos
50
51
52
Caso 1 Caso 2
1
0
0
1
1
1
Noviembre 2016
1
0
0
1
0
0
Caso 3
0
0
Caso 4
0
0
1
0
0
0
1
52
Casos de prueba definidos :

Casos
1
2
3
4
Entradas
Resultados Esperados
D5
Se muestra seccin 5
L4
Se muestra seccin 4
B2
COMANDO NO VALIDO
DA
NUMERO DE INDICE NO VALIDO
Noviembre 2016
53
Documentacin asociada a las

pruebas
Recomendaciones basadas en
estndares del IEEE
Documentacin asociada a las pruebas (1)

Docum. Proyecto
Espec. Diseo
Pruebas
Elem.Documentaci
n
Elemento Prueba
Plan de Pruebas
Espec. Diseo
Pruebas
Espec. Diseo
Pruebas
Espec. Caso
Prueba
Espec.
Procedim.
Prueba
Informe
Transmisin
Elementos
EJECUCIN PRUEBA
Noviembre 2016
55
Plan de pruebas
El propsito de este documento es
establecer el objetivo, aproximacin,
recursos y calendario de las actividades
de prueba, identificando los elementos
a probar, las caractersticas a probar,
las actividades a realizar, el personal
responsable de cada actividad y los
riesgos asociados.
Noviembre 2016
56
Especificaciones de diseo de las

pruebas
especificar los requisitos de la
aproximacin a las pruebas e identificar
las caractersticas que van a ser
probadas por este diseo y sus pruebas
asociadas.
Noviembre 2016
57
Especificacin caso de prueba

definir cada caso de los identificados en
la Especificacin de Diseo de las
pruebas.
Noviembre 2016
58
Especificacin procedimiento de
prueba
especificar los pasos para la realizacin
de los casos de prueba o de modo ms
general los pasos utilizados para
analizar un elemento software con el fin
de evaluar un conjunto de
caractersticas
Noviembre 2016
59
Informe de transmisin de elementos

de prueba
identificar los elementos necesarios
para una prueba. Esto incluye la
persona responsable de cada elemento,
su ubicacin y estatus.
Noviembre 2016
60
Documentacin asociada a las pruebas (2)
EJECUCIN PRUEBA
Informe Anomalia
Informe Realizacin
Informe Final
Noviembre 2016
61
Informe de realizacin de la
prueba
Este documento proporciona un registro
cronolgico de los detalles relevantes
relacionados con la ejecucin de las
pruebas.
Noviembre 2016
62
Informe de anomalas en prueba

El propsito de este informe es
documentar cualquier evento ocurrido
durante el proceso de prueba que
requiera una investigacin.
Noviembre 2016
63
Informe final de las pruebas

El propsito de este informe es resumir
los resultados de las actividades de
prueba y describir las evaluaciones
basadas en estos resultados.
Noviembre 2016
64

GC Pruebas

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

GC Pruebas

Diunggah oleh

Hak Cipta:

Format Tersedia

Gestin de Calidad en Direccin

Jos Luis Fernndez Snchez

Introduccin. Los procesos de gestin de la

Jos Luis Fernndez Snchez

Objetivo de la integracin y pruebas

Jos Luis Fernndez Snchez

Jos Luis Fernndez Snchez

Contexto de la I y V del Sistema

Requisitos del Usuario

Especificaciones y documentos de diseo

Paquete de diseo del sistema

Jos Luis Fernndez Snchez

Cada plan definir el entorno a utilizar, las

Jos Luis Fernndez Snchez

Jos Luis Fernndez Snchez

Definicin de la integracin y pruebas

Jos Luis Fernndez Snchez

Definicin de la integracin y pruebas

Jos Luis Fernndez Snchez

Ejecucin de la integracin y pruebas

Jos Luis Fernndez Snchez

Ejecucin de la integracin y pruebas

Jos Luis Fernndez Snchez

Jos Luis Fernndez Snchez

Concepto de pruebas del software

Jos Luis Fernndez Snchez

Niveles de pruebas (IEEE Std. 1059)

Pruebas realizadas para

Garantiza que la lgica

Una progresin ordenada de

Garantiza que los

Garantiza que el software

De cada prueba a los

Pruebas realizadas para

Garantiza que los

De cada prueba a los

Jos Luis Fernndez Snchez

Las pruebas en el ciclo de vida del

Fases del proyecto

Jos Luis Fernndez Snchez

Jos Luis Fernndez Snchez

Pruebas del sistema (I)

Jos Luis Fernndez Snchez

Pruebas del sistema (II)- Tipos

Jos Luis Fernndez Snchez

Jos Luis Fernndez Snchez

Se podra pensar en una realizacin de pruebas no incremental,

Jos Luis Fernndez Snchez

Pruebas de integracin descendentes

Jos Luis Fernndez Snchez

Jos Luis Fernndez Snchez

Pruebas de integracin descendentes

Lo mdulos representados como crculos son stubs o mdulos auxiliares

Jos Luis Fernndez Snchez

Pruebas de integracin descendentes

Lo mdulos representados como crculos son stubs o mdulos auxiliares

Jos Luis Fernndez Snchez

Pruebas de integracin descendentes

Lo mdulos representados como crculos son stubs o mdulos auxiliares

Jos Luis Fernndez Snchez

Jos Luis Fernndez Snchez

Jos Luis Fernndez Snchez

Pruebas de integracin ascendentesEjemplo

Jos Luis Fernndez Snchez