Upload
phamthuan
View
272
Download
0
Embed Size (px)
Citation preview
1
Pruebas de Software
Ingeniería del Software IUniversidad Rey Juan Carlos
CCéésar Javier Acusar Javier Acuññ[email protected]@urjc.es
Ingeniería del Software I2
Introducción
Verificación de Software:Determinar si los productos de una fase dada satisfacen las condiciones impuestas al inicio de la fase
Validación de Software:Evaluación de un sistema o uno de sus componentes durante o al final de su desarrollo para determinar si satisface los requisitos.
2
Ingeniería del Software I3
Introducción
Verificación¿Estamos construyendo correctamente el producto?
Validación¿Estamos construyendo el producto correcto?Estamos construyendo el producto correcto?
Las pruebas permiten validar y verificar el Las pruebas permiten validar y verificar el softwaresoftware
Ingeniería del Software I4
Introducción
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 evaluación de algún aspecto»
Caso de Prueba (test case): «un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular»
3
Ingeniería del Software I5
Introducción
Defecto (defect, fault, «bug»): «un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa»
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 »
Ingeniería del Software I6
Introducción
Error (error):La diferencia entre un valor calculado,
observado o medio y el valor verdadero, especificado o teóricamente correcto.Un defectoUn resultado incorrectoUna acción humana que conduce a un
resultado incorrecto .
4
Ingeniería del Software I7
Introducción
2 + 2 = 5
Error
Defecto (calidad)
¡Xyx//???
Sistema de gestión de aeropuerto
Fallo (fiabilidad)
S.Aproximación
Accidente(seguridad)
Equivocacióndel programador
Ingeniería del Software I8
Introducción
Probar exhaustivamente el SW es “imposible”Es imposible evaluar todas las posibilidadesUn proceso de prueba será exitoso cuando encuentre “errores”Los errores no son siempre fruto de la negligencia del programador
5
Ingeniería del Software I9
Introducción
RecomendacionesCada caso de prueba debe definir el resultado de salida esperadoEl programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemasSe debe inspeccionar a conciencia el resultado de cada prueba, así, poder descubrir posibles síntomas de defectos
Ingeniería del Software I10
Introducción
RecomendacionesAl generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados.Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo):
• Probar si el software no hace lo que debe hacer• Probar si el software hace lo que no debe hacer, es
decir, si provoca efectos secundarios adversos
6
Ingeniería del Software I11
Introducción
RecomendacionesSe deben evitar los casos desechables, es decir, los no documentados ni diseñados con cuidadoNo deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas.
Ingeniería del Software I12
Introducción
RecomendacionesLa 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 número de defectos ya descubierto.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.
7
Ingeniería del Software I13
El Proceso de Prueba
Planear pruebas
Planear pruebas
Diseñar pruebas
Diseñar pruebas
Ejecutar pruebas
Ejecutar pruebas
Evaluar pruebas
Evaluar pruebas
DepuraciónDepuración
Análisis deerrores
Análisis deerrores
DESARROLLODESARROLLO
Información sobre proyectoInformación sobre software(ERS, diseño, etc)
Plan de pruebas
Configuración depruebas (casos yprocedimientos)
Configuración desoftware revisada
Resultadosesperados
Errores:histórico einformes de pruebasAcciones preventivas
(formación, mejora deprocesos, etc)
Correcciones
Estadística deerrores
Predicción de fiabilidad
Resultados
Ingeniería del Software I14
Técnicas de Diseño de Casos de Prueba
Utilizamos técnicas para conseguir una confianza aceptable en que se detectarán los defectos existentesEquilibrio entre los recursos empleados y la confiabilidad de los casos de pruebaElegir los casos de prueba que puedan representar a los demas.La elección no debe ser al azar
8
Ingeniería del Software I15
Técnicas de Diseño de Casos de Prueba
Existen tres enfoques para el diseño de casos de prueba:
El enfoque estructural o de caja blancaEl enfoque funcional o de caja negraEl enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadísticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba
Ingeniería del Software I16
Técnicas de Diseño de Casos de Prueba
Caja blanca
Caja negra
Entrada
Entrada
Salida
Salida
Funciones
9
Ingeniería del Software I17
Pruebas Estructurales
El diseño de los casos debe basarse en la elección de caminos importantes que ofrezcan una seguridad aceptable.Se utilizan criterios de cobertura lógicaEs conveniente construir un diagrama de flujo de control (flowchart)
Ingeniería del Software I18
Pruebas Estructurales1
2
4
3
6
5
12,13
7a 7b
8,9
10,11
Abrir archivos;
Leer archivo ventas, al final indicar no más registros;
Limpiar línea de impresión;
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 más registros;
ENDWHILE;
Escribir línea de listado;
Limpiar área de impresión;
ENDWHILE;
Cerrar archivos.
10
Ingeniería del Software I19
Pruebas Estructurales
Cómo dibujar un grafo de flujoSeñalar sobre el código cada condición de cada decisión tanto en sentencias If-then y Case-of como en los bucles While o Until.Agrupar el resto de las sentencias en secuencias situadas entre cada dos condiciones .Numerar tanto las condiciones como los grupos de sentencias, de manera que se les asigne un identificador único
Ingeniería del Software I20
Pruebas Estructurales
Criterios de Cobertura De Sentencias: • Se trata de generar los casos de prueba necesarios
para que cada sentencia o instrucción del programa se ejecute, al menos, una vez.
De decisiones: • Consiste en escribir casos suficientes para que cada
decisión tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso.
11
Ingeniería del Software I21
Pruebas Estructurales
De condiciones: • Se trata de diseñar tantos casos como sea necesario
para que cada condición de cada decisión adopte el valor verdadero al menos una vez y el falso al menos una vez.
De decisión/condición. • Consiste en exigir el criterio de cobertura de
condiciones obligando a que se cumpla también el criterio de decisiones.
De condición múltiple. • En el caso de que se considere que la evaluación de
las condiciones de cada decisión no se realiza de forma simultánea.
Ingeniería del Software I22
Pruebas Estructurales
La cobertura de caminos es el criterio mas elevadoCada camino debe ser probadoCaminos de prueba: ejecutar cada bucle por lo menos una vezUtilizando caminos de prueba se puede cuantificar la cantidad de caminos (permite asignar correctamente los recursos)
12
Ingeniería del Software I23
Pruebas Estructurales
Complejidad Ciclomática de McCabe (V(G))Empleada para determinar el Nº de caminos independientes.Valor de la métrica es un buen criterioV(G)• a-n+2, siendo a el número de arcos y n el número de
nodos• r, siendo r el número de regiones cerradas• c+1, sindo c el número de nodos de condición
Ingeniería del Software I24
Pruebas Estructurales
1 2 43 65 11
78
9 10
a1a2
a3
a4 a5a6
a7
a8a9
a10
a11
a12
a13
a14
Regi
ón 2
Regi
ón 4
Regi
ón 3
Regi
ón 1
Regi
ón 5
13
Ingeniería del Software I25
Pruebas Estructurales
Para elegir los caminos independientes a probar se utiliza el “método del camino básico”Consiste en realizar variaciones sobre un camino de prueba típico que llamamos básico
1-2-111-2-3-4-10-21-2-3-4-5-10-21-2-3-4-5-6-7-91-2-3-4-5-6-8-9
Ingeniería del Software I26
Pruebas Funcionales
Particiones o Clases de EquivalenciaLas cualidades que definen un buen caso de prueba:
• Cada caso debe cubrir el máximo número de entradas
• Debe tratarse el dominio de valores de entrada dividido en un número 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
14
Ingeniería del Software I27
Pruebas Funcionales
El método consiste entonces en:• Identificación de las clases de equivalencia• Creación de los casos de prueba correspondientes
Identificación de las Clases de Equivalencia• Identificar las restricciones al formato y contenido de
los datos de las entradas• Identificar las clases de equivalencia:
• De datos Válidos• De Datos no Válidos o Erróneos
Ingeniería del Software I28
Pruebas Funcionales
Existen algunas reglas que ayudan a identificar clase:
• Si se especifica un rango de valores para los datos de entrada, se creará una clase válida y dos clases no válidas
• Si se especifica un número de valores, se creará una clase válida y dos no válidas
• Si se especifica una situación del tipo «debe ser» o booleana (por ejemplo, «el primer carácter debe ser una letra»), se identifican una clase válida («es una letra») y una no válida («no es una letra»)
15
Ingeniería del Software I29
Pruebas Funcionales
• 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 válida por cada valor y una no válida.
• 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.
Desarrollar los casos de prueba• Este proceso consta de los siguientes pasos
• Asignación de un número único a cada clase de equivalencia
Ingeniería del Software I30
Pruebas Funcionales
• Hasta que todas las clases de equivalencia hayan sido cubiertas por (incorporadas a) casos de prueba, se tratará de escribir un caso que cubra tantas clases válidas no incorporadas como sea posible
• Hasta que todas las clases de equivalencia no válidas hayan sido cubiertas por casos de prueba, escribir un caso para una única clase no válida sin cubrir.
16
Ingeniería del Software I31
Pruebas Funcionales
Ejemplo:Especificación
• Código área: número de 3 dígitos que no empieza ni por 0, ni por 1.
• Nombre de identificación: 6 caracteres.• Ordenes posibles: "cheque", "depósito", "pago
factura", "retirada de fondos".
Ingeniería del Software I32
Pruebas Funcionales
Ejemplo:
Condición de entrada Clases válidas Clases inválidasCódigo área (1) 200 ≤código ≤999 (2) código <200
(3) código >999(4) no es número
Nombre para identificar laoperación
(5) seis caracteres (6) menos de 6 caracteres(7) más de 6 caracteres
Orden (8) «cheque»(9) (10) (11)
(12) ninguna orden válida«depósito»«pago factura»«retirada de fondos»
17
Ingeniería del Software I33
Pruebas Funcionales
Casos válidos: 300 Nomina Depósito (1) (5) (9)400 Viajes Cheque (1) (5) (8)500 Coches Pago Factura (1) (5) (10)600 Comida Retirada Fondos (1) (5) (11)
Casos No Válidos180 (2)1032 (3)XY (4)<CR> (6)Regalos (7)Casa (12)
Ingeniería del Software I34
Pruebas Funcionales
Análisis de Valores Límites (AVL)Exploran las condiciones límites de un programa.Técnica Complementaria a las Clases de Equivalencia.Diferencias:• Más que elegir «cualquier» elemento como
representativo de una clase de equivalencia, se requiere la selección de uno o más elementos tal que los márgenes se sometan a prueba.
18
Ingeniería del Software I35
Pruebas Funcionales
• Más que elegir «cualquier» elemento como representativo de una clase de equivalencia, se requiere la selección de uno o más elementos tal que los márgenes se sometan a prueba.
• Más que concentrarse únicamente en el dominio de entrada (condiciones de entrada), los casos de prueba se generan considerando también el espacio de salida
Reglas:• 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
Ingeniería del Software I36
Pruebas Funcionales
• 2) Si la condición de entrada especifica un número 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• En esta regla 3 y 4, debe recordarse que:
• los valores límite de entrada no generan necesariamente los valores límite de salida
• no siempre se pueden generar resultados fuera del rango de salida (pero es interesante considerarlo).
19
Ingeniería del Software I37
Pruebas Funcionales
• 5) Si la entrada o la salida de un programa es un conjunto ordenado (por ejemplo, una tabla, un archivo secuencial, ...), los casos deben concentrarse en el primero y en el último elemento
Ingeniería del Software I38
Pruebas Funcionales
Conjetura de ErroresEnumerar una lista de errores comunesEn función de ella elaborar los casos de pruebaEs importante la intuición y la experienciaEjemplos:
• El valor cero es una situación propensa a error tanto en la salida como en la entrada
• Cuando se introduce un número variable de valores, centrarse en el caso de no introducir ningún valor y en el de un solo valor. También puede ser interesante un lista que tiene todos los valores iguales
20
Ingeniería del Software I39
Pruebas Funcionales
• Es recomendable imaginar que el programador pudiera haber interpretado algo mal en la especificación
• También interesa imaginar lo que el usuario puede introducir como entrada a un programa
Ingeniería del Software I40
Pruebas Aleatorias
Se simula la entrada de datos habitual de un programa.Se crean datos que sigan la frecuencia y la secuencia que tendrían en la prácticaSe usan generadores de pruebas:
Descripción de datos Secuencias de entradas posibles Probabilidad de ocurrencia
21
Ingeniería del Software I41
Enfoque práctico para generar los casos de prueba
Si la especificación contiene combinaciones de condiciones de entrada, comenzar formando sus grafos de causa-efecto (ayudan a la comprensión de dichas combinaciones).
En todos los casos, usar el análisis de valores-límites para añadir casos de prueba: elegir límites para dar valores a las causas en los casos generados asumiendo que cada causa es una clase de equivalencia.
Ingeniería del Software I42
Enfoque práctico para generar los casos de prueba
Identificar las clases válidas y no válidas de equivalencia para la entrada y la salida, y añadir los casos no incluidos anteriormente (¿cada causa es una única clase de equivalencia? ¿Deben dividirse en clases?).
Utilizar la técnica de conjetura de errores para añadir nuevos casos, referidos a valores especiales.
22
Ingeniería del Software I43
Enfoque práctico para generar los casos de prueba
Ejecutar los casos generados hasta el momento (de caja negra) y analizar la cobertura obtenida (usar herramientas de análisis de cobertura)
Examinar la lógica del programa para añadir los casos precisos (de caja blanca) para cumplir el criterio de cobertura elegido.
Ingeniería del Software I44
Documentación del Diseño de Pruebas
Especificación dediseño de pruebas
Especificación dediseño de pruebasPlan de pruebasPlan de pruebas
Especificación dediseño de pruebas
Especificación dediseño de pruebas
Especificación decaso de pruebas
Especificación decaso de pruebas
Especificación deprocedimiento
de pruebas
Especificación deprocedimiento
de pruebas
EjecuciónEjecución
Informes
Documentos relacionados con el diseño de pruebas según IEEE std. 829 -1998
23
Ingeniería del Software I45
Documentación del Diseño de Pruebas
Plan de PruebasSeñalar:• El enfoque• Los recursos • El esquema de actividades de prueba• Los elementos a probar• Las características• Las actividades de prueba• El personal responsable• Los riesgos asociados
Ingeniería del Software I46
Documentación del Diseño de Pruebas
Estructura Fijada en el estándar• Identificador único del documento (para la gestión de
configuración).• Introducción y resumen de elementos y características a probar.• Elementos software que se van a probar (p. ej., programas o
módulos).• Características que se van a probar.• Características que no se prueban.• Enfoque general de la prueba (actividades, técnicas,
herramientas, etc.).• Criterios de paso/fallo para cada elemento.• Criterios de suspensión y requisitos de reanudación.• Documentos a entregar (como mínimo, los descritos en el
estándar).
24
Ingeniería del Software I47
Documentación del Diseño de Pruebas
Estructura Fijada en el estándar• Actividades de preparación y ejecución de pruebas.• Necesidades de entorno.• Responsabilidades en la organización y realización de las
pruebas.• Necesidades de personal y de formación.• Esquema de tiempos (con tiempos estimados, hitos, etc.).• Riesgos asumidos por el plan y planes de contingencias para
cada riesgo.• Aprobaciones y firmas con nombre y puesto desempeñado.
Ingeniería del Software I48
Documentación del Diseño de Pruebas
Especificación del Diseño de PruebasObjetivo: Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las características que se deben probar con este diseño de pruebas.
Estructura Fijada por el estándar: • Identificador (único) para la especificación. Proporcionar también
una referencia del plan asociado (si existe).• Características a probar de los elementos software (y
combinaciones de características).
25
Ingeniería del Software I49
Documentación del Diseño de Pruebas
Estructura Fijada por el estándar: • Detalles sobre el plan de pruebas del que surge este diseño,
incluyendo las técnicas de prueba específica y los métodos de análisis de resultados.
• Identificación 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 característica o combinación de características ha pasado con éxito la prueba o no).
Ingeniería del Software I50
Documentación del Diseño de Pruebas
Especificación de un Caso de PruebaObjetivo: definir uno de los casos de prueba identificado por una especificación del diseño de las pruebas.Estructura Fijada por el estándar• Identificador único de la especificación.• Elementos software (p. ej., módulos) que se van a probar: definir
dichos elementos y las características que ejercitará este caso.• Especificaciones de cada entrada requerida para ejecutar el caso
(incluyendo las relaciones entre las diversas entradas; p. ej., la sincronización de las mismas).
• Especificaciones de todas las salidas y las características requeridas (p. ej., el tiempo de respuesta) para los elementos que se van a probar.
26
Ingeniería del Software I51
Documentación del Diseño de Pruebas
Estructura Fijada por el estándar• 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 (p. ej., listar los identificadores de los
casos que se van a ejecutar antes de este caso de prueba).
Ingeniería del Software I52
Documentación del Diseño de Pruebas
Especificación de un Procedimiento de PruebaObjetivo: especificar los pasos para la ejecución de un conjunto de casos de prueba o, más generalmente, los pasos utilizados para analizar un elemento software con el propósito de evaluar un conjunto de características del mismo.Estructura Fijada por el estándar• Identificador único de la especificación y referencia a la
correspondiente especificación de diseño de prueba.• Objetivo del procedimiento y lista de casos que se ejecutan con él.• Requisitos especiales para la ejecución (p. ej., entorno especial o
personal especial).
27
Ingeniería del Software I53
Documentación del Diseño de Pruebas
Estructura Fijada por el estándar• Pasos en el procedimiento. Además de la manera de registrar los
resultados y los incidentes de la ejecución, se debe especificar:• La secuencia necesaria de acciones para preparar la ejecución.• Acciones necesarias para empezar la ejecución.• Acciones necesarias durante la ejecución.• Cómo se realizarán las medidas (p. ej., el tiempo de respuesta).• Acciones necesarias para suspender la prueba (cuando los
acontecimientos no previstos lo obliguen).• Puntos para reinicio de la ejecución y acciones necesarias para el
reinicio en estos puntos.• Acciones necesarias para detener ordenadamente la ejecución.• Acciones necesarias para restaurar el entorno y dejarlo en la
situación existente antes de las pruebas.• Acciones necesarias para tratar los acontecimientos anómalos
Ingeniería del Software I54
Ejecución de las pruebasEJECUTAR PRUEBAS
EJECUTAR PRUEBAS
COMPROBAR TERMINACIÓN
COMPROBAR TERMINACIÓN
¿ALGÚNFALLO?
¿ALGÚNFALLO?
DEPURARPRUEBAS
DEPURARCÓDIGO
¿PRUEBASADICIONALES?
¿PRUEBASADICIONALES?CONDICIONES
ANORMALES
CONDICIONESANORMALES
NO
SÍ SÍ
EVALUARRESULTADOS
EVALUARRESULTADOS
PRUEBASADICIONALES
(DEFECTODEL SOFTWARE)
(DEFECTODE PRUEBAS)
TERMINACIÓNANORMAL
TERMINACIÓNNORMALNO
SÍ
NO
SÍ
CRITERIOS DECOMPLECIÓN DELPLAN DE PRUEBAS
28
Ingeniería del Software I55
Documentación de la Ejecución de las pruebas
Históricode pruebas(test log)
Históricode pruebas(test log)
Informe resumende las pruebas
Informe resumende las pruebas
Informesde incidentes
Informesde incidentes
ESPECIFICACIÓN DE LAS PRUEBASCASOSPROCEDIMIENTOS
EJECUCIÓNEJECUCIÓN
Históricode pruebas(test log)
Históricode pruebas(test log)
Informesde incidentes
Informesde incidentes...
Ingeniería del Software I56
Documentación de la Ejecución de las pruebas
Historico de PruebasDocumenta todos los hechos relevantes ocurridos durante la ejecución de las pruebas.
Informe de Incidente:Documenta cada incidente (p. ej., una interrupción en las pruebas debido a un corte de electricidad, bloqueo del teclado, etc.) ocurrido en la prueba y que requiera una posterior investigación.
29
Ingeniería del Software I57
Documentación de la Ejecución de las pruebas
Informe resumenResume los resultados de las actividades de prueba (las reseñadas en el propio informe) y aporta una evaluación del software, basada en dichos resultados.
Ingeniería del Software I58
Depuración
Es proceso de localizar, analizar y corregir los defectos que se sospecha que contiene el software. Suele ser la consecuencia de una prueba con éxito.Consecuencias
Encontrar la causa del error, analizarla y corregirlaNo encontrar la causa. (casos de prueba para depuración).
30
Ingeniería del Software I59
Sintomas de Errores
Depuración
Etapas:Localización del Error (mayor esfuerzo)Corrección del defecto
Casos de Prueba
Causas Correción
Causas
Ingeniería del Software I60
Análisis de errores o análisis causal
¿Cuándo se cometió?¿Quién lo hizo¿Qué se hizo mal?¿Cómo se podría haber prevenido?¿Por qué no se detectó antes?¿Cómo se podría haber detectado antes?¿Cómo se encontró el error?
31
Ingeniería del Software I61
Ciclo de Vida de Pruebas (V)
Contrato.Requisitos de
usuario
Contrato.Requisitos de
usuario
Especificación de requisitos del
software
Especificación de requisitos del
software
Documentación de diseño y arquitectura
Documentación de diseño y arquitectura
Especificación de módulos o elementos
Especificación de módulos o elementos
CódigoCódigo
Prueba de unidad
Prueba de unidad
Prueba de aceptación
Prueba de aceptación
Prueba de sistema
Prueba de sistema
Prueba de integración
Prueba de integración
ExhaustivaEnfoque recomendado:Caja negraCobertura de pruebas
InterfacesMezcla con pruebade unidadTipos de integración
Requisitos nofuncionalesDocumentación
PlanificarTipos:AlfaBeta
Ingeniería del Software I62
Pruebas de Unidad
Puede abarcar desde un módulo, a un grupo de pocos módulos o un programa completo Las pruebas de unidad suelen ser realizadas por personal de desarrollo Utilizar el enfoque práctico ya visto.
32
Ingeniería del Software I63
Pruebas de IntegraciónLigadas a la forma prevista de integrar los distintos componentes del software hasta contar con el producto global que debe entregarseTipos de Integración
Incremental (ascendente y descendente)• Se combina el siguiente módulo que se debe probar
con el conjunto de módulos que ya están probados
No Incremental• Se prueba cada módulo por separado y, luego, se
integran todos de una vez y se prueba el programa completo
Ingeniería del Software I64
Pruebas del SistemaVerifica:
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.Adecuación de la documentación de usuario.Ejecución y rendimiento en condiciones límite y de sobrecarga.
33
Ingeniería del Software I65
Pruebas de AceptaciónObjetivo
Comprobar si el producto está listo para ser implantado para el uso operativo en el entorno del usuario.
CaracterísticasParticipación del UsuarioEstá enfocada hacia la prueba de los requisitos de usuario especificadosEstá considerada como la fase final del proceso para crear una confianza en que el producto es el apropiado para su uso en explotación