INGENIERÍA DE SOFTWARE II
1
¿Qué es probar? ¿Para qué se prueba?
Vista
Presentación
Vista de Vista
Impleme
ntación Lógica
Vista de
Despliegue
¿Son importantes las pruebas
en el desarrollo del software?
“Probar es la parte inevitable de cualquier
esfuerzo responsable por desarrollar un
sistema de software.”
[William Howden]
3
DISCIPLINA
INGENIERÍA Y GESTIÓN DE SOFTWARE
ASIGNATURA
INGENIERÍA DE SOFTWARE II
Actividad 17.
Tema 2. Verificación y validación de
software.
Conferencia 6. Introducción a la
verificación y validación de software.
4
OBJETIVO
Caracterizar la verificación y
validación de software, teniendo en
cuenta técnicas estáticas y dinámicas,
métodos, tipos y niveles de prueba
para contribuir a una estrategia de
evaluación consistente.
5
CONTENIDOS
Procesos de verificación y validación
del software.
Métodos de prueba.
Tipos de prueba.
Niveles de prueba.
Estrategia de prueba.
6
BIBLIOGRAFÍA
Pressman, Roger S. (2010). Ingeniería de Software:
un enfoque práctico. 7ma Edición. Editorial McGraw-
Hill. Nueva York, E.U.A. Capítulo 17: Estrategia de
prueba de software (Págs. 383-409). Capítulo 18:
Pruebas de aplicaciones convencionales. Capítulo 20:
Pruebas de aplicaciones web (Págs. 453-475).
Sommerville, Ian. (2011). Ingeniería de Software,
9na Edición. Editorial Pearson Education S.A.
Madrid, España. Capítulo 8: Pruebas de software
(Pág. 205-228).
7
PUNTOS CLAVE
La construcción de un sistema de
software tiene como objetivo
satisfacer una necesidad
planteada por un cliente.
8
ALGUNAS INTERROGANTES
Una vez construido ese sistema de software:
¿El producto desarrollado se corresponde
exactamente con lo que el cliente me
pidió?
¿El producto desarrollado va a funcionar
correctamente?
Una de las posibles soluciones a este problema podría ser que
el cliente evalúe el sistema que se ha desarrollado una vez
terminado. 9
IMPLICACIONES
10
¿Qué se
recomienda?
11
RECOMENDACIONES
Evaluar el producto de software a medida que
se vaya construyendo.
Entregar productos incrementales y
satisfactorios que se retroalimenten.
Analizar el comportamiento de atributos de
calidad sobre el producto.
12
ATRIBUTOS DE CALIDAD
Funcionalidad: Habilidad del software para
realizar el trabajo deseado.
Fiabilidad: Habilidad del software para
mantenerse operativo (funcionando).
Eficiencia: Habilidad del software para
responder a una petición de usuario con la
velocidad apropiada.
13
ATRIBUTOS DE CALIDAD
Usabilidad: Habilidad del software para
satisfacer al usuario.
Mantenibilidad: Habilidad del software para
poder realizar cambios en él rápidamente y con
una adecuada proporción cambio/costo.
Portabilidad: Habilidad del software para
ejecutarse en diferentes entornos informáticos.
14
¿Cómo catalogar los
hallazgos identificados al
evaluar un producto?
15
HALLAZGOS
Error: Acción humana que produce una falta.
Falta: Algo que está mal en un producto
(modelo, código, documento, entre otros).
Fallo: Manifestación de una falta.
Oportunidad de mejora: grado de mejorar algo.
Defecto: error, falta, fallo.
16
¿Qué proceso(s) se
encarga(n) de identificar
estos hallazgos?
17
VERIFICACIÓN Y VALIDACIÓN
(V&V)
Conjunto de procesos de comprobación y
análisis que aseguran que el software que se
desarrolla está acorde a su especificación y
cumple las necesidades de los clientes.
Existen actividades de V&V en cada etapa del
proceso de desarrollo del software.
18
¿Implican lo mismo? ¿En
qué difieren?
19
VERIFICACIÓN Y VALIDACIÓN
(V&V)
Verificación:
¿Estamos construyendo el producto
correctamente?
Validación:
¿Estamos construyendo el producto
correcto?
[Pressman (Boehm, 1981)]
20
VERIFICACIÓN Y VALIDACIÓN
(V&V)
Verificación:
¿Construimos bien el producto?
Validación:
¿Construimos el producto correcto?
[Somerville (Boehm, 1979)]
21
VERIFICACIÓN
¿Estamos construyendo el producto
correctamente?
Comprobar que el software está de
acuerdo a su especificación.
Cumplimiento de los requisitos funcionales
y no funcionales según su especificación.
22
VALIDACIÓN
¿Estamos construyendo el producto correcto?
Proceso más general.
Su objetivo es demostrar que el software
hace lo que el cliente espera que haga para
cumplir con sus expectativas.
23
VERIFICACIÓN Y VALIDACIÓN
OBJETIVO
Establecer confianza de que el sistema de
software es “adecuado”.
El nivel de confianza requerido depende del
propósito del sistema, las expectativas de los
usuarios del sistema y el entorno de mercado
actual.
Significa que el sistema tiene que ser bastante
eficaz para su uso esperado.
24
VERIFICACIÓN Y VALIDACIÓN
ACTIVIDADES DE CALIDAD
La verificación y la validación incluyen un amplio
arreglo de actividades de aseguramiento de la
calidad:
Revisiones técnicas.
Auditorías de calidad y configuración.
Monitoreo de rendimiento.
Simulación.
Revisión de base de datos.
Revisión de documentos.
Pruebas de desarrollo, usabilidad, aceptación,
instalación, entre otras. 25
VERIFICACIÓN Y VALIDACIÓN
TÉCNICAS
Existen aproximaciones complementarias
para el análisis y comprobación de los
sistemas:
Inspecciones del software.
Las pruebas del software.
26
VERIFICACIÓN Y VALIDACIÓN
INSPECCIONES DEL SOFTWARE
Analizan y comprueban las representaciones del
sistema tales como: documentos de requerimientos,
los diagramas de diseño y el código fuente del
programa.
Pueden usarse inspecciones en todas las etapas del
proceso.
Pueden ser complementadas con algún tipo de análisis
automático del código fuente de un sistema o de los
documentos asociados.
Las inspecciones de software y los análisis automáticos
son técnicas de V&V estáticas, ya que no se necesita
ejecutar el software. 27
VERIFICACIÓN Y VALIDACIÓN
INVOLUCRADOS GENÉRICOS
Rol Descripción
Autor o Programador o diseñador responsable de generar el
Propietario programa o documento. Responsable de reparar los
defectos encontrados.
Inspector Encuentra errores, omisiones e inconsistencias en los
programas y documentos.
Lector Presenta el código o documento en una reunión de
inspección.
Secretario Registra los resultados de la reunión de inspección.
Presidente o Gestiona el proceso y facilita la inspección. Realiza
moderador informe de resultados del proceso.
Moderador Responsable de las mejoras, actualización de las listas
jefe de comprobación, estándares de desarrollo.
28
¿Cómo verificar que la
documentación está
correcta?
29
LISTAS DE CHEQUEO
Luonsa arcecqióunisibto
iesn dsefinaindaliqzan
ue
revisiones de artefactos
sested meábteicam reeanlitzear pcoorn uenl
e
soqfutiw
paordee. revisores.
procedimiento compuesto
rveearlifziacradoys. los
por seis pasos.
esperados.
39
LISTAS DE CHEQUEO
Formulario de preguntas, las cuales dependen
del objetivo para el cual son usadas. Es fácil de
aplicar, resumir y comparar.
Proporciona un apoyo mayor mediante
preguntas que los probadores deben responder
mientras leen el artefacto. Esta técnica
proporciona listas que ayudan al probador a
saber qué tipo de faltas buscar.
31
LISTAS DE CHEQUEO
EJEMPLO
Lista de chequeo para evaluar un CU:
Nombre del CU:
¿Está en infinitivo y refleja de manera clara el
objetivo del usuario sobre el sistema?
¿El nombre del caso de uso es único?
¿El nombre del caso de uso es intuitivo?
¿El nombre del caso de uso es explicativo?
Sobre el Resumen o Descripción:
¿Recoge las acciones fundamentales del CU?
32
¿Qué son las técnicas de
V&V de Pruebas del
software?
33
VERIFICACIÓN Y VALIDACIÓN
PRUEBAS DEL SOFTWARE
Implican ejecutar una implementación del
software con datos de prueba.
Se examinan las salidas del software y su
entorno operacional para comprobar que
funciona tal y como se requiere.
Las pruebas son una técnica dinámica.
Requiere disponer de prototipo ejecutables, por
lo que sólo pueden utilizarse en ciertas fases del
proceso.
34
PRUEBAS
La prueba es un proceso de ejecución de un
programa con la intención de descubrir errores.
Un buen caso de prueba es aquel que tiene una
alta probabilidad de mostrar un error no
descubierto hasta entonces.
Una prueba tiene éxito si descubre un error no
detectado hasta entonces.
35
PRUEBAS
El objetivo de la prueba es diseñar pruebas que
saquen a la luz diferentes clases de errores con
la menor cantidad de tiempo y espacio.
La prueba no puede asegurar la ausencia de
defectos, solo pueden demostrar que existen
defectos en el software.
36
PRUEBAS
PROPÓSITO
Su principal objetivo es evaluar y valorar la
calidad del producto a través de:
Buscar y documentar errores
Validar el cumplimiento de requerimientos
Validar el desempeño
Dar una indicación
de calidad
37
PRUEBAS
PRINCIPALES ROLES
Rol Responsabilidad
Probador Es el responsable durante las actividades
principales de las pruebas.
Diseñador de prueba Es el responsable de definir y aplicar los
métodos de prueba y asegurar su
implementación exitosa.
Administrador o Es el responsable documentar el éxito de las
Coordinador de prueba, su planificación, dirección y
prueba administración de recursos.
Analista de prueba Es el responsable de identificar y definir las
pruebas requeridas, monitorear el progreso
de la prueba y el resultado en cada ciclo de
prueba. 38
VERIFICACIÓN Y VALIDACIÓN
PRUEBAS DEL SOFTWARE
Las pruebas se realizan en 4 etapas:
Prueba de aceptación: Se prueba el sistema en un
entorno de desarrollo real y del usuario final.
Prueba de sistema: Se prueba el sistema como un
todo.
Prueba de integración: Se prueban agrupaciones de
clases relacionadas.
Prueba de unidad: Se prueba cada método y clase
de forma independiente.
El descubrimiento de un defecto en una etapa requerirá la repetición de
las etapas de prueba anteriores. 39
VERIFICACIÓN Y VALIDACIÓN
TÉCNICAS DURANTE EL PDS
40
¿Cómo planificar y
gestionar estas técnicas
de prueba?
41
ELEMENTOS A TENER EN CUENTA
PARA QUE UNA PRUEBA TENGA ÉXITO
• Estrategia de
Existe una dependencia
Prueba
jerárquica entre estos
conceptos, por lo que
• Niveles de Prueba vamos a comenzar a
estudiar primero los
Tipos de Prueba métodos hasta la
estrategia.
Métodos de Prueba
Casos de Prueba 42
43
MÉTODOS DE PRUEBA
Pruebas de Caja Negra:
Se llevan a cabo sobre la interfaz del software.
Demostrar que las funciones del software son operativas,
que las entradas se aceptan de forma adecuada y se
produce un resultado correcto, y que la integridad de la
información externa se mantiene (no se ve el código).
Pruebas de Caja Blanca:
Se llevan a cabo sobre la código fuente del software.
Se comprueban los caminos lógicos del software.
Examinar el estado del programa en varios puntos para
determinar si el estado real coincide con el esperado.
44
MÉTODO DE PRUEBA
PRUEBAS DE CAJA NEGRA
Se centran principalmente en los requisitos funcionales
del software.
Permiten encontrar:
Funciones incorrectas o ausentes.
Errores de interfaz.
Errores en estructuras de datos o en accesos a las
bases de datos externas.
Errores de rendimiento.
Errores de inicialización y terminación.
45
MÉTODO DE PRUEBA
PRUEBAS DE CAJA BLANCA
Requieren del conocimiento de la estructura interna
del programa.
Estas pruebas deben garantizar como mínimo que:
1. Se ejerciten por lo menos una vez todos los caminos
independientes para cada módulo.
2. Se ejerciten todas las decisiones lógicas en sus
vertientes verdaderas y falsa.
3. Ejecuten todos los bucles en sus límites y con sus
límites operacionales.
4. Se ejerciten las estructuras internas de datos para
asegurar su validez. 46
¿Qué técnicas aplicar
para el método de caja
negra?
47
PRUEBAS DE CAJA NEGRA
TÉCNICAS
Para desarrollar las pruebas de caja negra existen varias
técnicas:
Técnica de partición de equivalencia.
Técnica de análisis y valor límite.
Técnica de grafos de causa-efecto.
Técnica más utilizada “partición de equivalencia”
48
PRUEBAS DE CAJA NEGRA
TÉCNICA DE PARTICIÓN DE EQUIVALENCIA
Permite examinar los valores válidos e inválidos
de las entradas existentes en el software.
Descubre de forma inmediata una clase de
errores que, de otro modo, requerirían la
ejecución de muchos casos antes de detectar el
error genérico.
49
¿Qué es un caso
de prueba?
50
CASO DE PRUEBA
Conjunto de entradas de pruebas, condiciones de
ejecución y resultados esperados desarrollados para
cumplir un objetivo en particular o una función
esperada.
Debe verificar:
Si el producto satisface los requerimientos del
usuario, tal y como se describe en las especificación
de los requerimientos.
Si el producto se comporta como se desea, tal y como
se describe en las especificaciones funcionales del
diseño.
51
ESTRUCTURA DE UN
CASO DE PRUEBA
Id del Escenario Variable 1 Variable 2 Variable N Respues Resultad
escen (Nombre de (Nombre de (Nombre ta del o de la
ario la variable) la variable) de la Sistema Prueba
variable)
EC 1 Nombre del V V V Se Se
escenario. escribe el escribe el
Dato real Dato real Dato real resultado resultado
que se que se
espera al obtiene al
realizar realizar la
la prueba.
prueba.
Los valores de las variables pueden ser Válidos (V), Inválidos (I),
52
No Aplica (N/A).
EJEMPLO
DE CASO DE PRUEBA
Caso de uso: Gestionar libros.
Sección 1: Registrar libros.
Id del Escenari Código Nombre Cantidad Respuesta del Resultado de
escena o Sistema la Prueba
rio
EC 1.1 Entrada V V V Muestra un Se registró
de datos BN2345 Había 20 mensaje satisfactoriam
válidos. una vez indicando: ente un libro.
“Registro
satisfactorio”.
EC 1.2 Ausencia V I I Muestra un Se alertó
de BN4567 (Vacío) (Vacío) mensaje satisfactoriam
campos indicando: ente la
obligatori “Existen ausencia de
os. campos datos.
vacíos”.
(Continuación) 53
EJEMPLO
DE CASO DE PRUEBA
Id del Escenar Código Nombr Cantida Respuesta Resultado
escen io e d del Sistema de la
ario Prueba
EC 1.3 Existenci V V V Muestra un Se alertó
a de ese TY345 La 5 mensaje satisfactoria
libro. edad indicando: “Ya mente la
de oro existe ese existencia
libro”. de un libro.
EC 1.4 Seleccio N/A N/A N/A Recarga el Se limpiaron
na el - - - formulario con satisfactoria
botón los campos mente los
Cancelar vacíos. datos del
. formulario.
54
EJEMPLO
DE CASO DE PRUEBA
55
¿Qué técnicas aplicar
para el método de caja
blanca?
56
PRUEBAS DE CAJA BLANCA
TÉCNICAS
Para desarrollar las pruebas de caja blanca existen
varias técnicas:
Camino básico.
Condición.
Flujo de datos.
Bucles.
Técnica más utilizada “camino básico”
57
PRUEBAS DE CAJA BLANCA
TÉCNICAS
La prueba de condición: Es un método de diseño de
casos de prueba que ejercita las condiciones lógicas
contenidas en el módulo de un programa.
La prueba de flujo de datos: Se selecciona caminos de
prueba de un programa de acuerdo con la ubicación de
las definiciones y los usos de las variables del
programa.
La prueba de bucles: Es una técnica de prueba de caja
blanca que se centra exclusivamente en la validez de las
construcciones de bucles. 58
PRUEBAS DE CAJA BLANCA
TÉCNICA DE CAMINO BÁSICO
Esta técnica permite obtener una medida de la
complejidad lógica de un diseño y usar esta medida
como guía para la definición de un conjunto básico.
La idea es derivar casos de prueba a partir de un
conjunto dado de caminos independientes por los
cuales puede circular el flujo de control.
Para obtener dicho conjunto de caminos
independientes se construye un grafo de flujo asociado
y se calcula su complejidad ciclomática.
59
PRUEBAS DE CAJA BLANCA
TÉCNICA DE CAMINO BÁSICO
Pasos:
1. A partir del diseño o del código fuente, se dibuja el
grafo de flujo asociado.
2. Se calcula la complejidad ciclomática del grafo.
3. Se determina un conjunto básico de caminos
independientes.
4. Se preparan los casos de prueba que obliguen a la
ejecución de cada camino del conjunto básico.
Los casos de prueba derivados del conjunto básico
garantizan que durante la prueba se ejecuta por lo menos una vez
cada sentencia del programa 60
PRUEBAS DE CAJA BLANCA
TÉCNICA DE CAMINO BÁSICO
Paso 1: Diseñar el grafo de flujo
61
PRUEBAS DE CAJA BLANCA
TÉCNICA DE CAMINO BÁSICO
Paso 1: Diseñar el grafo de flujo
Un grafo de flujo está formado por 3
componentes:
Nodos.
Aristas.
Regiones.
62
PRUEBAS DE CAJA BLANCA
TÉCNICA DE CAMINO BÁSICO
Paso 1: Diseñar el grafo de flujo
Nodo:
Cada círculo representado se denomina nodo del
Grafo de Flujo, el cual representa una o más
secuencias procedimentales.
Un solo nodo puede corresponder a una secuencia
de procesos o a una sentencia de decisión.
Puede ser también que hallan nodos que no se
asocien, se utilizan principalmente al inicio y final del
grafo. 63
PRUEBAS DE CAJA BLANCA
TÉCNICA DE CAMINO BÁSICO
Paso 1: Diseñar el grafo de flujo
Arista:
Las flechas del grafo se denominan aristas y
representan el flujo de control, son análogas a las
representadas en un diagrama de flujo.
Una arista debe terminar en un nodo, incluso
aunque el nodo no represente ninguna sentencia
procedimental.
64
PRUEBAS DE CAJA BLANCA
TÉCNICA DE CAMINO BÁSICO
Paso 1: Diseñar el grafo de flujo
Regiones:
Las regiones son las áreas delimitadas por las aristas
y nodos.
También se incluye el área exterior del grafo,
contando como una región más.
Las regiones se enumeran y la cantidad de regiones
es equivalente a la cantidad de caminos
independientes del conjunto básico de un programa.
65
PRUEBAS DE CAJA BLANCA
TÉCNICA DE CAMINO BÁSICO
Paso 2: Calcular la complejidad ciclomática
La complejidad ciclomática es una métrica de software
que proporciona una medición cuantitativa de la
complejidad lógica de un programa.
El valor calculado como complejidad ciclomática define
el número de caminos independientes del conjunto
básico de un programa y nos da un límite superior para
el número de pruebas a realizar.
Un camino independiente es cualquier camino del
programa que introduce por lo menos un nuevo
conjunto de sentencias. 66
PRUEBAS DE CAJA BLANCA
TÉCNICA DE CAMINO BÁSICO
Paso 2: Calcular la complejidad ciclomática
Existen 3 formas para calcular la complejidad
ciclomática:
El número de regiones cerradas que se forman entre los
nodos y las aristas más la abierta del grafo.
V(G), se define como: V(G) = A - N + 2. Donde: A es el
número de aristas del grafo y N es el número de nodos.
V(G), también se define como: V(G) = P + 1. Donde: P es
el número de nodos predicado contenidos en el grafo.
Si el resultado de la complejidad ciclomática por las 3 formas es el mismo,
entonces podemos considerar el grafo de flujo correcto. 67
PRUEBAS DE CAJA BLANCA
TÉCNICA DE CAMINO BÁSICO
Ejemplo:
Paso 1:
Paso 2:
V(G) = 2 V(G) = P + 1 = 1 + 1 = 2
Paso 3: 68
PRUEBAS DE CAJA BLANCA
TÉCNICA DE CAMINO BÁSICO
Paso 4: Diseño de casos de prueba
Caso de uso: Mostrar libro.
Caso de prueba: Obtener libro.
Camino: 1, 2, 4.
Entrada: Código válido de un libro del listado de
catálogos.
Resultados: Se devuelve un objeto de tipo CE_Libro.
Condiciones: Que el código ISBN introducido se
encuentre dentro del catálogo de libros.
Trabajo independiente: Diseñe el caso de prueba para el
camino 1, 3, 4. 69
REGISTRO DE DEFECTOS
Y DIFICULTADES
Eleme No No Aspecto Signif No Recom Estado NC Respuesta del
nto confor correspondie icativ Signific endació Equipo Desarrollo
midad nte a ativa n
Nomb x Descri Descripción X X X Se coloca el Esta columna es
re del pción del Aspecto estado de la responsabilidad
Elem de la correspondie NC y la fecha, del equipo de
ento. No nte. cada vez que desarrollo, quien
Confor se revise se especifica la
midad deja el estado conformidad con
. anterior y se lo encontrado o
coloca el no y en caso de
nuevo con la no proceder la no
fecha en que conformidad
se revisó. explica por qué.
RA: Resuelta
PD:
Pendiente
NP: No
Procede.
70
71
TIPOS DE PRUEBA
Cada tipo de prueba tiene un objetivo específico y
técnicas que lo soportan.
Tipos de Prueba Sub-característica
Funcionalidad Función, Seguridad, Volumen
Usabilidad
Fiabilidad Integridad, Estructura, Stress
Rendimiento Contención, Carga, Profile
Soportabilidad Configuración, Instalación
72
FUNCIONALIDAD
Función: Fijan su atención en la validación de las
funciones, métodos, servicios, casos de uso.
Seguridad: Asegurar que los datos o el sistema
solamente es accedido por los actores deseados.
Volumen: Enfocada en verificando las
habilidades de los programas para manejar
grandes cantidades de datos, tanto como
entrada, salida o residente en la BD.
73
USABILIDAD
Prueba enfocada a factores humanos, estéticos,
consistencia en la interfaz de usuario, ayuda
sensitiva al contexto y en línea, asistente
documentación de usuarios y materiales de
entrenamiento.
74
FIABILIDAD
Integridad: Enfocada a la valoración de la robustez,
resistencia a fallos.
Estructura: Enfocada a la valoración a la adherencia a
su diseño y formación. Este tipo de prueba es hecho a
las aplicaciones web asegurando que todos los enlaces
están conectados, el contenido deseado es mostrado.
Stress: Enfocada a evaluar cómo el sistema responde
bajo condiciones anormales. Sobrecarga, insuficiente
memoria, servicios y hardware no disponible, recursos
compartidos. 75
FIABILIDAD
Contención: Enfocada a analizar la demanda de
múltiples actores sobre un mismo recurso (registro de
recursos, memoria, entre otros).
Carga: Usada para validar y valorar la aceptabilidad de
los límites operacionales de un sistema bajo carga de
trabajo variable.
Profile: Enfocadas a monitorear el tiempo en flujo de
ejecución y acceso a datos en llamada a funciones,
identificando cuellos de botellas.
76
SOPORTABILIDAD
Configuración: Enfocada a asegurar que funciona en
diferentes configuraciones de hardware y software.
Instalación: Enfocada a asegurar la instalación en
diferentes configuraciones de hardware y software bajo
diferentes condiciones (insuficiente espacio en disco,
entre otros).
77
78
NIVELES DE PRUEBA
La prueba es aplicada para diferentes tipos de
objetivos, en diferentes escenarios o niveles de
trabajo.
Se distinguen los siguientes niveles de pruebas:
Prueba de desarrollador.
Prueba independiente.
Prueba de Unidad.
Prueba de Integración.
Prueba de Sistema.
Prueba de Aceptación. 79
NIVELES DE PRUEBA
PRUEBA DE RECUPERACIÓN
PRUEBA DE SEGURIDAD
PRUEBA DE RESISTENCIA
PRUEBA DE RENDIMIENTO 80
81
ESTRATEGIA DE PRUEBA
Describe el enfoque y los objetivos generales de las
actividades de prueba.
Incluye los niveles de prueba (unidad, integración,
entre otros) a aplicar, los tipos de prueba a ejecutar
(funcional, stress, entre otros) y los casos de prueba
diseñados para lograr los objetivos.
Define:
Técnicas de pruebas (manual o automática) y
herramientas a utilizar.
Criterios de éxitos y culminación de la pruebas.
Consideraciones especiales relacionadas con los
recursos. 82
ESTRATEGIA DE PRUEBA
PLANTILLA
83
ESTRATEGIA DE PRUEBA
84
ESTRATEGIA DE PRUEBA
85
ESTRATEGIA DE PRUEBA
86
AUTOMATIZACIÓN DE
LAS PRUEBA
Uso de herramientas informáticas para llevar a
cabo las pruebas:
JMeter (Carga y Stress).
JUnix (Unidad en java).
NUnit (Unidad en .NET).
DBMonster (Rendimiento).
Bugzilla (Seguimiento de defectos).
Selenium (Funcionalidad).
87
PROCESO DE DESARROLLO DE
SOFTWARE EN LA UCI
Actividad de desarrollo-producción
Nivel 2
Referencia: Metodología_UCI.pdf
vUCI
88
PROCESO DE DESARROLLO DE
SOFTWARE EN LA UCI
Expediente de desarrollo Ed. 4.0 (CP) y 5.0:
Plan de [Link] (Nivel 2)
Plan de verificación y
validació[Link] (Nivel 3)
Diseño de casos de [Link]
89
INDETIFICA EL TÉRMINO A
PARTIR DE LA IMAGEN
Nombre: Identifica el término a partir de la imagen.
Descripción: Se presentará una imagen aleatoria que sugiere un
término sobre los contenidos de la clase. Al identificar el
término se deberá argumentar con características relacionadas.
Tiempo: 30 segundos.
Puntuación: 5 puntos.
90
INDETIFICA EL TÉRMINO A
PARTIR DE LA IMAGEN
Sugiere un nivel de pruebas
91
INDETIFICA EL TÉRMINO A
PARTIR DE LA IMAGEN
Sugiere una técnica de V&V
92
INDETIFICA EL TÉRMINO A
PARTIR DE LA IMAGEN
Sugiere una técnica de Pruebas
93
INDETIFICA EL TÉRMINO A
PARTIR DE LA IMAGEN
Sugiere un nivel de Pruebas
94
INDETIFICA EL TÉRMINO A
PARTIR DE LA IMAGEN
Sugiere una técnica de V&V
95
INDETIFICA EL TÉRMINO A
PARTIR DE LA IMAGEN
Sugiere un tipo de Pruebas
96
INDETIFICA EL TÉRMINO A
PARTIR DE LA IMAGEN
Sugiere métodos de Pruebas
97
INDETIFICA EL TÉRMINO A
PARTIR DE LA IMAGEN
Sugiere una técnica de Pruebas
98
CONCLUSIONES
El objetivo de la prueba de software es descubrir
errores.
Es necesario planificar las pruebas, definiendo la
estrategia a seguir en cada una de ellas.
En todas las fases del desarrollo del proyecto hay que
probar el software que se va construyendo.
La etapa de prueba es tan o más importante que todas
las realizadas hasta el momento puesto que en ella se
refleja la calidad con que ha sido llevada a cabo la
proyección del sistema.
99
TRABAJO INDEPENDIENTE
Trabajo independiente #2:
1. Realizar la “Estrategia de Prueba” de sus trabajos de
curso.
Guía de realización y evaluación:
1. Utilizar la plantilla explicada en la conferencia.
2. Llevar a la próxima clase.
3. Evaluación en la próxima clase (Clase Práctica 8).
100
PRÓXIMA ACTIVIDAD
• Actividad 24.
• Tema 2. Verificación y validación de software.
• Clase Práctica 8. Diseño de estrategias de
prueba. Diseño de pruebas de caja blanca.
101
DISCIPLINA
INGENIERÍA Y GESTIÓN DE SOFTWARE
ASIGNATURA
INGENIERÍA DE SOFTWARE II
Actividad 17.
Tema 2. Verificación y validación de
software.
Conferencia 6. Introducción a la
verificación y validación de software.
102
