UNIVERSIDAD NACIONAL DEL SANTA
VÍCERRECTORADO ACADÉMICO
FACULTAD DE INGENIERÍA
ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS E
INFORMATICA
ASIGNATURA
Ingeniería de Software I
2024 - I
Mg. Ing. Luis Enrique Ramirez Milla
Ingeniería de software I
Unidad III
Gestión del desarrollo de software
Competencias de la unidad didáctica
Gestiona el desarrollo de software
V
PROGRAMACION ACADEMICA
UNIDAD 3
Gestión del desarrollo de software
Contenidos:
Pruebas de software
12
¿Cual es el problema?
¿Cómo probar que un sistema
software está haciendo algo bien/mal?
¿Cómo diseñar las pruebas?
¿Por qué es un problema importante?
Ejemplos de fallos
¿Como hacer pruebas?
Mas tarde, mas caro
Etapas donde se producen errores
Momentos de prueba
Desarrollo guiado por pruebas
TDD: Test Driven Development
Desarrollo guiado por pruebas
• Mientras antes • Se pierde el diseño
Desventajas
Ventajas
pruebe detecto • No siempre es
errores aplicable en la
• Desarrollo practica (GUIs)
incremental • Muy dependiente de
• Aumenta la las habilidades de
productividad prueba de los
• Reduce tareas de desarrolladores
depuración
Definiciones
Verificación
Proceso para determinar si los
productos de una determinada
fase del desarrollo software
cumplen con los requisitos de la
fase previa. ¿El sistemas
software está haciendo algo
correctamente?
Validación
Proceso de evaluar el software al
final del desarrollo para
asegurar su conformidad con el
uso que se le quiere dar. ¿El
sistema software es el que
necesito? ¿nos falta algo? ¿nos
sobra algo?
Demostración Formal
Análisis que permite afirmar que la
implementación cumple sus requisitos.
Prueba
Análisis que permite aumentar nuestra
confianza en que la implementación cumple
sus requisitos
• Failure: (fallo): Incapacidad de un sistema para realizar su función, es
decir, hay una diferencia entre lo que se espera que haga el sistema y
lo que está haciendo el sistema. Se podría definir como “los síntomas”.
• Fault: (bug): Es lo que provoca el fallo. Se podría definir como “la
causa”
• Error: Estado interno de un programa que contiene un bug. Algunos
estados no revelan un fallo.
• Testing: Evaluar el software observando su ejecución.
• Debugging: El proceso de encontrar un bug
Condiciones para observar un fallo (RIP)
Accesibilidad (R:Reachability): El lugar/lugares dónde se
encuentra el fallo deben ser accedidos
Infección (I): Una vez accedido el estado del programa
debe ser incorrecto
Propagación (P): El estado infectado debe propagarse
para poder observar su estado
Proceso general
Proceso de general de prueba
Un caso de prueba se suele documentar identificando los siguientes
puntos (IEEE Standard for Software Testing Documentation):
• Identificador del caso de prueba.
• Entradas
• Salidas esperadas
• Dependencias (si es necesario ejecutar antes otros casos de
prueba)
Actividades
Actividades en pruebas
Se pueden distinguir cuatro tipos de actividades
1. Diseño
1.1 Basado en criterios
1.2 Basado en conocimiento
2. Automatización
3. Ejecución
4. Evaluación
Cada actividad requiere distintas competencias pero es frecuente que se
use a la misma persona para las cuatro actividades (no recomendado,
especialmente para sistemas complejos y críticos)
Diseño
Diseño de casos de prueba
Las posibles entradas de un
Un plan de pruebas exhaustivo
programa pueden (y suelen) ser
es impracticable
infinitas.
El objetivo de un buen banco de
pruebas (test set, test suite):
pocas entradas, muchos fallos.
Criterio de cobertura: Conjunto ¿Cómo seleccionar las
de reglas que imponen una entradas? Usando un criterio
serie de requisitos a un banco de cobertura (coverage
de pruebas criteria)
Clasificación
Pruebas unitarias
Están diseñadas para ejercitar
una parte pequeña y especifica Acotamos el ámbito de un fallo
de funcionalidad
Prueban que una pequeña parte
aislada del software es A veces no se pueden evitar las
correcta dependencias
No debe ir mas allá de sus Es una habilidad que se aprende
limites con la práctica
Grupos de criterios
Técnicas para el diseño de casos de prueba
1. Particiones equivalentes
• Se divide el espacio de prueba en clases equivalentes
• Las particiones deben ser “disjuntas”
• Inconveniente: rápida explosión
2. Valores límite
• Según esta técnica los errores en los programas suelen estar en los
valores límite de las entradas de un programa.
• Se prueban los valores límite de las particiones equivalentes en caso
de haberlas
Ejemplo
El precio de la matrícula depende de la edad del cliente y hay tres
rangos: menores de 18 años, entre 18 y 65 y mayores de 65.
Tres (3) clases equivalente:
• Usamos los valores límite: 17,18,19,64,65,66
• O simplificando (el límite y los adyacentes): 17, 18, 64, 65
3. Combinacion: Pair - Wise
Pairwisetesting(también 2-wise testing). Es un método dentro
de los llamados “combinatorios” que propone hacer pruebas
sobre todas las posibles combinaciones de 2 parámetros de
entrada
La hipótesis que maneja es que la mayoría de los errores son
debidos a errores en un parámetro de entrada, la siguiente es
la combinación de pares de parámetros de entrada, etc.
3. Combinacion: Pair - Wise
• 12.288 combinaciones = 212x 3
• Con pair-wise se reduciría ese
número
Imagina X, Y, Z
booleanos:
4. Errores conocidos (Error Guessing)
• Errores comunes según nuestra
experiencia
• Ejemplo: Cuándo se almacena un
“cliente” se puede almacenar
con el mismo ID
5. Cobertura CRUD
• Para cada elemento persistente,
se prueban todas sus
operaciones CRUD
• Cada caso de prueba comienza
por una C, seguida por todas las
U y se termina por una D
• Tras cada C, U o D, se ejecuta
una R que nos sirve de oráculo
UNIVERSIDAD NACIONAL DEL SANTA
VÍCERRECTORADO ACADÉMICO
FACULTAD DE INGENIERÍA
ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS E
INFORMATICA
ASIGNATURA
Ingeniería de Software I
2024 - I
