Testing primera parcial

Clase 1 - PRUEBA (TESTING) Y MANTENIMIENTO DE SOFTWARE

Roles en el proceso de Desarrollo de Software
• Líder de Proyecto Administrador del Proyecto: Coordina el equipo y asegura que
todos los demás roles cumplan con su trabajo.
• Analista Funcional: Genera los requerimientos para el sistema para definir la estructura
básica del mismo.
• Diseñador: Genera los requerimientos para el sistema para definir la estructura básica del
mismo.
• Desarrollador: Es el que toma los requerimientos y prototipos y los traduce a código
ejecutable
• Tester/Probador: Es el que asegura la calidad del producto
Testing: Las pruebas de software o Testing es el proceso permite identificar posibles fallos en
la implementación, calidad o usabilidad de un programa. No solo significa ejecutar pruebas,
sino que incluye las actividades de planificación, preparación y evaluación de productos de
software para determinar si cumple con los requerimientos especificados.
• Un error es un problema humano durante la fase de desarrollo.
• Un defecto es un problema en el código como resultado de un error.
• Un fallo es la manifestación visible del defecto cuando el software se ejecuta y no cumple
con los requisitos esperados.
Requisito: Un requisito describe un atributo funcional deseado u obligatorio, Un requisito en
testing es una condición o función que debe cumplirse o ser evaluada para determinar si un
sistema cumple con los criterios de aceptación establecidos. Ej: "El sistema de login debe
permitir a los usuarios registrados acceder a la plataforma utilizando un nombre de usuario y
una contraseña válidos".
Pueden ser:
• Requisitos Funcionales: Se enfocan en qué debe hacer el sistema. Ejemplos:
Autenticación, búsqueda, gestión de carritos, procesamiento de pedidos.
• Requisitos No Funcionales: Se enfocan en cómo debe comportarse el sistema.
Ejemplos: escalabilidad, Rendimiento, seguridad, disponibilidad, usabilidad.
Ejemplo de Requisito Funcional Ejemplo de Requisito No Funcional
Requisito: El sistema de gestión de Requisito: El sistema debe poder manejar
inventarios debe permitir a los usuarios 1000 solicitudes de búsqueda
buscar productos por nombre, categoría o simultáneamente sin degradar su
código de producto. rendimiento

Caso de Prueba: Caso de Prueba:

Identificador: RF001 Identificador: RNF001
Descripción: Verificar que el sistema Descripción: Verificar que el sistema
permite buscar productos por nombre. maneja 1000 solicitudes de búsqueda
Precondiciones: El usuario debe haber simultáneamente sin degradar el
iniciado sesión en el sistema. rendimiento.
Precondiciones: El sistema debe estar en un
entorno de prueba con la capacidad de
simular múltiples usuarios.
 Pasos: Pasos:
• Navegar a la página de búsqueda de • Configurar un simulador de carga
productos. para generar 1000 solicitudes de
• Ingresar el nombre completo o parcial de un búsqueda simultáneas.
producto en el campo de búsqueda. • Ejecutar el simulador de carga.
• Hacer clic en el botón de búsqueda. • Monitorear el rendimiento del
sistema durante la prueba
Resultados Esperados: El sistema debe Resultados Esperados: El sistema debe
mostrar una lista de productos que procesar las 1000 solicitudes de búsqueda
coincidan con el nombre ingresado simultáneamente y mantener el tiempo de
respuesta por debajo de 2 segundos para
cada solicitud.

Calidad: La Calidad es el grado en el cual un componente, sistema o proceso satisface

requisitos especificados y/o necesidades y expectativas del cliente. Ej: Un ejemplo de calidad
en testing podría ser el desarrollo de pruebas exhaustivas y rigurosas para garantizar que un
software cumpla con los requisitos y expectativas establecidos.
Ejemplo de Calidad de Software
Proyecto: Aplicación Web de Comercio Electrónico
Atributos de Calidad:
Funcionalidad:
Requisito: La aplicación debe permitir a los usuarios buscar productos, agregar productos al
carrito, realizar pagos y gestionar sus cuentas.
Métrica de Evaluación: El 100% de las funciones principales deben estar implementadas y
probadas exitosamente.
Fiabilidad:
Requisito: La aplicación debe estar disponible y operativa el 99.9% del tiempo. Métrica de
Evaluación: El tiempo de inactividad no debe exceder los 8.76 horas al año
Atributos de Calidad
Funcionales No funcionales
• Correctitud: La correctitud Atributos de • Fiabilidad: Se mantiene la capacidad y
Calidad /corrección en el testing se funcionalidad del sistema a lo largo de
refiere a la capacidad de un sistema o un periodo de tiempo.
software de producir los resultados Métricas de Evaluación:
correctos de acuerdo con las Tiempo Medio Entre Fallos (MTBF): El
especificaciones y requisitos tiempo promedio que el sistema opera
establecidos. Ejemplo: Un sistema de sin fallos. Tasa de Fallos: La frecuencia
gestión de inventarios debe registrar con la que ocurren fallos en el sistema.
correctamente todas las transacciones de Ejemplo de Pruebas: Pruebas de
entrada y salida de productos sin errores. Resistencia: Ejecutar el sistema durante
• Completitud: En el contexto del testing un periodo prolongado para identificar
(pruebas) de software, la completitud se fallos potenciales.
refiere a la medida en que se han • Usabilidad: fácil de usar, fácil de
realizado todas las pruebas diseñadas y aprender, uso intuitivo.
planificadas para un sistema o Métricas de Evaluación:
componente de software específico. Tiempo para Completar Tareas: El
Ejemplo: Una aplicación de comercio tiempo que los usuarios tardan en
 electrónico debe incluir todas las completar tareas específicas.
funcionalidades especificadas, como Satisfacción del Usuario: Evaluaciones
búsqueda de productos, gestión de subjetivas de los usuarios sobre la
carrito, y procesamiento de pagos facilidad de uso. Ejemplo de Pruebas:
Pruebas de Usabilidad con Usuarios:
Realizar sesiones de prueba con usuarios
reales para observar y medir cómo
interactúan con el sistema.
• Portabilidad: fácil de instalar y
desinstalar y configurar parámetros.
• Eficiencia: El sistema necesita solo la
utilización de un mínimo de recursos
para ejecutar una tarea determinada.
• Mantenibilidad: Esfuerzo necesario para
realizar cambios en los componentes de
un sistema
Por qué son necesarias las pruebas
• El software es realizado por seres humanos que cometen errores.
• A medida que se incrementa la presión en las entregas, no hay tiempo para chequear y
se comienza a asumir, con lo cual se cometen errores
• A medida que se incrementa la presión en las entregas, no hay tiempo para chequear
y se comienza a asumir, con lo cual se cometen errores
• Porque las fallas pueden ser costosas: Es más barato y rápido encontrar las fallas antes
de poner el sistema en producción
Ejemplos reales
El Caso de la Radiografía Therac-25 Windows Vista
Descripción: Therac-25 fue una máquina de Descripción: Windows Vista fue una versión
radioterapia utilizada en los años 1980. del sistema operativo Windows lanzada por
Problema: Tenía defectos de software que Microsoft en 2007.
no fueron identificados debido a la falta de Problema: El sistema operativo fue lanzado
pruebas rigurosas. Estos defectos permitían con numerosos problemas de rendimiento,
dosis de radiación excesivas. compatibilidad y usabilidad debido a la falta
Consecuencia: Varias personas murieron o de pruebas exhaustivas.
sufrieron graves lesiones por radiación. Consecuencia: La mala recepción por parte
Lección: Este caso resaltó la importancia de de los usuarios y las empresas llevó a una
las pruebas de software en sistemas críticos adopción limitada y a una reputación dañada
para la vida y la necesidad de implementar para Microsoft en ese momento.
redundancias y verificaciones manuales. Lección: Subraya la importancia de las
pruebas de usabilidad y compatibilidad, así
como la necesidad de escuchar y responder
a las retroalimentaciones de los usuarios
beta.
Objetivos las pruebas
• Adquirir conocimiento • Generación de la Información
• Confirmación de la funcionalidad • Confianza
Cuánto testing es necesario
Probar todas las combinaciones posibles es algo casi imposible. Para determinar cuándo
terminar las pruebas, existen los riesgos y las prioridades. Es bastante subjetivo y depende de
cada proyecto
No encontrar más defectos puede ser un criterio para terminar con las actividades de pruebas.
Sin embargo, cada prueba debe contar con criterios de salida (“ exit criteria ”). Al alcanzar
estos criterios de salida concluirán las actividades de prueba
Ejemplo: Las pruebas se consideran completas cuando se han corregido todos los defectos
críticos y de alta prioridad, y al menos el 95% de los casos de prueba han sido ejecutados con
éxito.
• Pruebas basadas en riesgos: El nivel de riesgo determinará el grado en el cual se harán
las pruebas. Ejemplo: En un sistema de control de tráfico aéreo, se destinan recursos
adicionales y se realizan pruebas exhaustivas en los módulos de comunicación y
navegación debido a su alto riesgo.
• Pruebas basadas en plazos y presupuesto: La disponibilidad de recursos de personal,
tiempo, presupuesto. Ejemplo: En una aplicación móvil con presupuesto limitado y fecha
de lanzamiento fija, se priorizan las pruebas de funciones principales y se automatizan las
pruebas de regresión para maximizar la cobertura dentro del tiempo y presupuesto
disponibles
Proceso Fundamental de Testing
La ejecución de pruebas es sólo una parte del proceso de las pruebas. Dependiendo del
enfoque seleccionado el proceso de pruebas se realizará en diferentes puntos del proceso de
desarrollo.
Estos procesos son:
• Control: las tareas de control son
o Medición y análisis de los o Proporción de información
resultados (Stakeholders)
o Monitoreo y documentación o Inicio de acciones
o Toma de decisiones
• Planificación: las tareas de planificación son:
o Alcance/Riesgos o Adquisicion de recursos
o Objetivos de las pruebas o Condiciones de prueba
o Enfoque de pruebas
Los documentos del plan de prueba son: Plan de pruebas, Estrategias de pruebas,
Enfoque de pruebas.
• Análisis y Diseño
o Revision de elementos o Diseño de casos
o Testeabilidad o Entorno
o Condiciones de pruebas o Herramientas
• Implementación y ejecución
o Finalización de casos de prueba o Comparación
o Trazabilidad o Informe
o Ejecución o Repetición
o Registro de resultados
• Evaluación de criterio de salida y reportes
o Comparación o Evaluación o Reporte
• Actividades de cierre
o Recoleccion o Análisis de lecciones
o Verificacion aprendidas
o Documetacion
Modelo de Desarrollo de software: Los modelos de desarrollo software son utilizados para
el desarrollo de software incluyendo las actividades del proceso de pruebas
El Modelo V: Busca reducir el riesgo
que existe entre lo que el usuario
necesita y el producto final. Cada
iteración contribuye con una
característica adicional del sistema a
desarrollar. En cada iteración, la
verificación (relación con el nivel
precedente) y la validación (grado de
corrección del producto dentro del
nivel actual) se pueden efectuar por
separado.
Algunos modelos iterativos
• Rup: Modelo orientada a objeto y producto de la compañía ibm
• Xp: No hay especificación de requisitos formalizada
• Scrum: Conjunto de buenas prácticas.
Clase 2 - Diseño de pruebas
¿Qué es un caso de prueba?: Son un conjunto de condiciones y variables bajo las cuales el
analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio.
Existen dos tipos de casos de prueba:
Los casos de prueba positivos muestran de la funcionalidad, y los casos de prueba
negativos comprueban situaciones en las que hay tratamiento de errores.
Ejemplo: tengo un requisito que dice que el precio de un producto debe ser mayor que 0.
• Casos de prueba positivos: precio igual a 0, precio igual a 10, precio igual a 15
• Caso de prueba negativo: precio igual a -5. En este caso, el sistema tiene que poder
determinar que es una situación de error y enviar el error a la aplicación.
Ejemplo de Casos de Prueba Positivos Ejemplo de Casos de Prueba Negativos
Los casos de prueba positivos son diseñados Los casos de prueba negativos están
para verificar si el sistema hace lo que se diseñados para verificar cómo el sistema
supone que debe hacer bajo condiciones maneja entradas o condiciones inesperadas
normales y con entradas válidas. o incorrectas. Ayudan a asegurar que el
Escenario: Función de login en un sitio software maneja graciosamente los errores
web. sin fallar.
Caso de Prueba Positivo: Escenario: Función de login en un sitio
Descripción: Iniciar sesión con credenciales web.
válidas. Caso de Prueba Negativo:
Pasos:
 • Ingresar a la página de login. Descripción: Intento de inicio de sesión
• Introducir un nombre de usuario válido con contraseña incorrecta.
(usuario_correcto). Pasos:
• Introducir una contraseña válida • Ingresar a la página de login.
(contraseña_correcta). • Introducir un nombre de usuario
• Hacer clic en el botón "Iniciar sesión". válido (usuario_correcto).
Resultado Esperado: El usuario debería ser • Introducir una contraseña incorrecta
redirigido a la página de inicio después de (contraseña_incorrecta).
un login exitoso. • Hacer clic en el botón "Iniciar
sesión".
Resultado Esperado: El sistema debería
mostrar un mensaje de error que indique que
la contraseña es incorrecta y no permitir el
acceso al usuario
Niveles de prueba: Dependiendo de en qué momento del proceso de desarrollo son
ejecutadas las pruebas, tenemos diferentes niveles:
1. Testing unitario: Se realiza durante la fase de desarrollo, justo después de que se
escriben las unidades individuales de código. Tiene como objetivo verificar que cada
unidad funcione correctamente de manera aislada. Un defecto que se encuentra
normalmente en este tipo de pruebas son los de procesamiento de datos, normalmente en
el entono de los valores límite: si el precio de un producto tiene que ser mayor a 0 que
pasa cuando es 0.
Características
• Pruebas luego de su construcción • Realizado por desarrolladores
• Incrementar confianza • Se utiliza métodos de caja blanca

2. Testing de integración: Ocurre después del testing unitario. Una vez que las unidades
individuales están probadas, se integran en módulos o grupos para testear las
interacciones entre ellas. Tiene como objetivo asegurarse de que los módulos o
componentes del software funcionen correctamente cuando se combinan. El propósito de
esta prueba es detectar defectos en las interfaces entre los defectos mas comunes podemos
encontrar: Perdida de datos, Manipulación de datos, Los componentes interpretan datos
de entrada de manera diferente.
Características
• Prueba de integración entre • Realizado por desarrolladores o testers
componentes • Se utiliza métodos de caja blanca o
• Realizado luego del testing unitario negra
3. Testing de sistema: Se realiza después de completar el testing de integración. En esta
etapa, todo el sistema software se prueba en un entorno que simula la producción. Tiene
como objetivo verificar el comportamiento completo del sistema y asegurarse de que
cumple con los requisitos especificados.
Características
• Prueba de comportamiento de todo • Prueba de requerimientos
el sistema funcionales y no funcionales
• Punto de vista de usuario
 • Se utiliza métodos de caja negra
4. Testing de aceptación: Es el último nivel de prueba antes de que el software sea
entregado al cliente o puesto en producción. Usualmente se realiza después del testing de
sistema. Para este tipo usamos solo métodos de caja negra
Características
• Prueba de verificación formal
• Tipos
o Testing de aceptación interno
o Testing de aceptación externo
Tipos de pruebas
• Funcionales: Se puede realizar en todos los niveles de prueba, tiene como objetivo que el
objetivo realmente funcione, permite verificar los requisitos funcionales.
o Adecuación: Verifica si el software proporciona funciones que satisfacen las
necesidades especificadas. Ej.: Si el sistema registra usuarios correctamente.
o Exactitud: Evalúa si el software proporciona los resultados correctos con el nivel
de precisión requerido. Ej.: En una aplicación de cálculo de impuestos, la exactitud
se probaría ingresando varios escenarios de datos fiscales.
o Interoperabilidad: Determina si el software es capaz de interactuar con otros
sistemas y dentro de su entorno de forma adecuada. Ej.: Para un software que debe
integrarse con sistemas de terceros.
o Cumplimiento de la funcionalidad: Verifica que el software cumple con todas las
funciones especificadas. Ej.: En un software educativo, se verificaría que todas las
funciones listadas en los documentos de especificaciones.
o Seguridad: Asegura que el software protege la información y mantiene la
privacidad y la integridad de los datos. Ej.: En una aplicación bancaria, la seguridad
se probaría intentando realizar ataques como inyección SQL, XSS, o intentos de
acceso no autorizado.
• No funcionales: Diseñadas para evaluar el comportamiento del sistema en condiciones
específicas más allá de las funciones puras del software. Tiene como objetivo es saber
como funciona el sistema, se puede llevar a cabo en todos los niveles de pruebas.
o Volumen: Evalúa la capacidad del sistema para manejar grandes volúmenes de
datos. Ej.: ara una base de datos, se podría probar cómo maneja la inserción y
consultas.
o Estabilidad: Asegura que el software es capaz de operar bajo carga durante
periodos prolongados sin degradación del servicio. Ej.: Un sistema de reservas
online podría ser sometido a pruebas de estabilidad ejecutándolo a capacidad
máxima durante 24 horas.
o Robustez: Mide la capacidad del sistema para manejar condiciones erróneas o
extremas. Ej.: Intentar romper una aplicación web mediante la inyección de código
malicioso o entradas no válidas para ver cómo maneja los errores
o Usabilidad: Evalúa qué tan fácil y agradable es para los usuarios finales usar el
software Ej.: Llevar a cabo estudios de usuario para determinar la facilidad de uso
de una aplicación móvil.
 o Rendimiento: Prueba cuán efectivo es el software en términos de velocidad de
respuesta y estabilidad bajo carga. Ej.: Medir el tiempo de respuesta de un servidor
web múltiples simultáneamente.
o Carga: Examina el comportamiento del sistema bajo cargas de trabajo esperadas y
picos de carga. Ej.: Simular múltiples usuarios accediendo a un sistema de comercio
electrónico durante un evento de ventas para verificar si puede manejar picos de
tráfico.

• Estructural o caja blanca: La finalidad de las pruebas es medir el grado en el que la

estructura del objeto de prueba ha sido cubierta por los casos de prueba, pueden realizarse
en todos los niveles, pero sobre todo en las pruebas de componentes y de integración.
o Medir el grado por el caso de prueba
Ejemplo Práctico
Imagina que estás desarrollando un sistema de gestión de inventario. Uno de los componentes
clave es una función que calcula el número total de artículos en el inventario después de cada
transacción. La función toma dos argumentos: el número actual de artículos y la cantidad de
la transacción, que puede ser positiva (añadir stock) o negativa (vender stock).
• Relacionada a cambios: El objetivo es repetir una prueba de funcionalidad que ha sido
verificada previamente
o Confirmación: Las pruebas de confirmación, también conocidas como pruebas de
retest, se realizan para asegurarse de que los defectos identificados durante las
pruebas previas han sido corregidos. El objetivo es verificar si las correcciones
implementadas en el código no solo resuelven el defecto sin introducir nuevos
problemas, sino que también funcionan en el contexto esperado.
Ejemplo Práctico: Supongamos que en un sistema de gestión de clientes se
identificó un defecto donde el sistema no guardaba correctamente la dirección de
los clientes si contenía caracteres especiales. Después de que los desarrolladores
modifican el sistema para manejar correctamente estos caracteres: Entrada de
prueba: Guardarladirección"CalleNueva#123, Ciudad@Sol“ Resultado esperado:
La dirección se guarda correctamente sin errores y se muestra exactamente como
fue ingresada.
 o Regresión: Las pruebas de regresión se utilizan para asegurarse de que cambios
recientes en el código, como correcciones de errores, mejoras o actualizaciones, no
afecten negativamente a las funcionalidades existentes que previamente
funcionaban bien. Estas pruebas son cruciales para mantener la estabilidad del
sistema a lo largo de múltiples iteraciones y actualizaciones.
Ejemplo Práctico: En el mismo sistema de gestión de clientes, además de la
corrección de la dirección, se agregó una nueva funcionalidad para importar
contactos desde un archivo CSV. Las pruebas de regresión incluirían: Pruebas sobre
funcionalidades no relacionadas con la importación, como la creación de nuevos
clientes, la edición y eliminación de clientes existentes, para asegurar que estas
funcionalidades siguen operando correctamente después de la nueva
implementación. Pruebas específicas para la nueva funcionalidad de importación,
asegurando que se importan correctamente los datos y que no se introducen errores
en otras partes del sistema
TIPOS DE TECNICAS
El test estático encuentra defectos mientras que el test dinámico encuentra fallas o
desviaciones en el resultado esperado.
Técnicas Dinámicas: Ambas complementarias técnicas ya Técnicas basadas en experiencia
son que detectan diferentes tipos de errores.
• Caja Negra: Verificamos las funcionalidades. Seleccionamos un conjunto de entradas y
salidas. Se usa en todos los niveles: componente, integración, sistema y aceptación.
o Partición de valores de equivalencia
▪ Dividimos los posibles valores en clases (mediante esto se observa valores
de entrada de un programa y valores de salida)
▪ CE= comportamiento común (ejemplo x sea verdadero)
▪ Tenemos CE validas y CE invalidas
o Análisis de valores limite
▪ Amplia la técnica anterior
▪ También seleccionamos representantes
o Tablas de decisión: Las decisiones son una herramienta utilizada en las pruebas de
caja negra para modelar decisiones lógicas complejas. Ayudan a identificar las
condiciones y acciones posibles, proporcionando una estructura clara para las
pruebas.
▪ Tiene en cuenta dependencias y combinaciones
▪ Usamos gráficos de causa efecto y las tablas de decisión
o Pruebas de transición de estados
▪ Los demás métodos usan entradas y salidas
▪ Usamos diagramas de transición de estados

o Pruebas de caso de uso

▪ Los casos de prueba se obtienen directamente de casos de uso
▪ Se utilizan en pruebas de aceptación y de sistema
• Basadas en experiencia
• Caja Blanca: Accedemos al código del programa. Se realiza sobre las funciones internas
de un módulo. Se usa en los niveles: componente, integración y sistema
o Cobertura de sentencia: La cobertura es la medida en que un conjunto de pruebas
ha probado una estructura, pero expresada como porcentaje (Por ejemplo: se probó
el 15% o el 80% de la estructura del módulo).
▪ Comprobamos el número de sentencias ejecutadas
▪ Utilizamos el grafico de flujo de control: La base de este
análisis es el gráfico (o diagrama) de flujo de control donde las
instrucciones están representadas por nodos y el flujo de
control entre instrucciones está representado por flechas.
▪ 𝑐𝑜𝑏𝑒𝑟𝑡𝑢𝑟𝑎 = (𝑛𝑟𝑜.𝑑𝑒 𝑠𝑒𝑛𝑡𝑒𝑛𝑐𝑖𝑎𝑠 𝑒𝑗𝑒𝑐𝑢𝑡𝑎𝑑𝑎𝑠/ 𝑛𝑟𝑜.𝑡𝑜𝑡𝑎𝑙 𝑑𝑒
𝑠𝑒𝑛𝑡𝑒𝑛𝑐𝑖𝑎𝑠 )×100
▪ Objetivo: detectamos bloques no usados
Estos casos de prueba están diseñados para
evaluar cómo el algoritmo maneja diferentes
entradas para las variables A y B. El algoritmo
suma A y B, y si el resultado es mayor que 10,
imprime el resultado

o Cobertura de decisión: Una decisión es un punto en el código en el que se produce

una ramificación. Entonces se satisface el criterio de cobertura de decisión si todas
las condiciones del programa son ejecutadas ya sea por verdadero (True) o falso
(False). La cobertura de decisión se centra en el flujo de control en un segmento de
programa (no los nodos sino las aristas del diagrama de flujo de control). Todas
ellas deben ser cubiertas por lo menos una vez.
▪ Comprobamos el número de aristas ejecutadas
▪ Utilizamos el grafico de flujo de control
▪ 𝑐𝑜𝑏𝑒𝑟𝑡𝑢𝑟𝑎 =(𝑛𝑟𝑜.𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖𝑜𝑛𝑒𝑠 𝑒𝑗𝑒𝑐𝑢𝑡𝑎𝑑𝑎𝑠 /𝑛𝑟𝑜.𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖𝑜𝑛𝑒𝑠)
×100
▪ Una cobertura de decisión del 100% siempre incluye una cobertura de
sentencia del 100%

Ejecución delos Casos de Prueba

Al ejecutar estos casos de prueba, garantizamos que todas las decisiones en el código (las
condiciones número > 0, numero < 0 y la condición implícita número == 0) sean evaluadas
tanto para su resultado verdadero como falso, logrando así una cobertura de decisión
completa.
Conjunto de Pruebas para Cobertura de Decisión
Para asegurar la cobertura de decisión completa, debemos probar cada posible camino de
ejecución en el código. Aquí tienes los casos de prueba necesarios:
Caso de Prueba 1:
Entrada: numero = 5
Descripción: Evalúa la condición numero > 0 como verdadera.
Resultado Esperado: "El número es positivo"
Caso de Prueba 2:
Entrada: numero = -3
Descripción: Evalúa la condición numero < 0 como verdadera.
Resultado Esperado: "El número es negativo" Caso de Prueba 3: Entrada: numero = 0
Descripción: Evalúa la condición numero > 0 y numero < 0 como falsas.
Resultado Esperado: "El número es cero
Caso de Prueba 3:
Entrada: numero = 0
Descripción: Evalúa la condición numero > 0 y numero < 0 como falsas.
Resultado Esperado: "El número es cero"

o Cobertura de camino
▪ Comprobamos el número de caminos linealmente independientes
▪ 𝑐𝑜𝑏𝑒𝑟𝑡𝑢𝑟𝑎 =( 𝑛𝑟𝑜.𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖𝑜𝑛𝑒𝑠 𝑒𝑗𝑒𝑐𝑢𝑡𝑎𝑑𝑎𝑠 /𝑛𝑟𝑜.𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 caminos)
×100
▪ Mas exhaustiva que la cobertura de sentencia y decisión
o Pruebas de condición y cobertura :
▪ Porcentaje de todos los resultados individuales de condición que afecta al
resultado de una decisión
▪ Detectamos defectos que provienen de implementar condiciones múltiples
Técnicas Estáticas: Las técnicas estáticas pueden realizarse antes dinámicas defectos para
antes conviertan en fallas de las encontrar que se
• Revisiones
o Tipos
▪ Revisión Informal: revisión entre pares, es la revisión más simple ya
que no tiene un proceso formal.
▪ Revisión Guiada: este tipo de revisión está liderada por el Autor del
documento, quien a lo largo de la presentación va mostrando el
artefacto a revisar, mientras que los revisores hacen preguntas.
▪ Revisión Técnica: Es una revisión formal o informal, donde participan
técnicos expertos, preferentemente externos a la organización y es
liderada por un moderador, no el autor.
▪ Inspección: Revisión formal, cuenta con procesos de preparación,
ejecución, documentación y seguimiento).
 • Análisis con Herramientas: Lo que buscan estas herramientas es PREVENIR
defectos antes de ejecutar las pruebas, para advertir aspectos sospechosos del código,
detectando inconsistencias.
Mediante el análisis estático con herramientas se comprueban:
o Reglas y estándares de programación
o Diseño de un programa (la herramienta es: análisis del flujo de control
o Uso de datos (la herramienta es: análisis del flujo de datos)
o Complejidad de la estructura de un programa (la herramienta es: métrica)
Las herramientas son:
o Compiladores: Detecta errores sintácticos en el código fuente, comprueba
consistencias entre tipos de variables, detecta variables no declaradas.
o Analizadores: trata convenciones y estándares, acoplamiento de objetos.
• Análisis de flujo de control
• Análisis de flujo de datos
• Métricas del compilador
Clase 4 –

Clase 5 –

Clase 6 – Revisión y Auditoria

Proceso de revisión: El objetivo de una revisión de un elemento de software es de evaluar el
software o el estado del proyecto para identificar las discrepancias sonre los resultados
planificados y recomendar mejoras cuando sea apropiado. Su objetivo es de evaluar el estado
y los productos del software
Tipos de Revisiones
• SRR: Revisión de Requisitos de Sistema: La SRR es una evaluación formal de los
requisitos del sistema para asegurar que sean completos, coherentes y verificables. Se
revisan los requisitos para asegurarse de que cumplen con las necesidades del cliente
y que son factibles para su desarrollo e implementación.
• SFR o SDR: Revisión Funcional del Sistema ó Revisión de Diseño del Sistema: La
SFR o SDR es una revisión del diseño funcional del sistema. Aquí se verifica que el
diseño del sistema cumpla con los requisitos establecidos en la SRR. Esta revisión
asegura que el sistema en desarrollo funcionará como se espera y que todos los
requisitos funcionales han sido abordados en el diseño.
• SSR: Revisión de Especificación Software: La SSR es una revisión formal de las
especificaciones del software para asegurarse de que todos los requisitos del sistema
se traduzcan correctamente en especificaciones de software. Es un paso crítico para
garantizar que el software desarrollado cumpla con las expectativas y requisitos
definidos.
• PDR: Revisión del Diseño Preliminar: La PDR es una revisión del diseño preliminar
de un sistema o componente. Se realiza para asegurar que el diseño inicial cumple con
todos los requisitos y que es viable para proceder a un diseño más detallado. Es una
 etapa donde se identifican riesgos potenciales y se sugieren mejoras antes de avanzar
al diseño detallado.
• CDR: Revisión del Diseño Detallado: La CDR es una revisión exhaustiva del diseño
detallado del sistema, donde se verifica que el diseño es completo, funcional y listo
para la fase de producción o desarrollo. Esta revisión asegura que el diseño cumple
con todos los requisitos y que el sistema puede construirse según las especificaciones
sin problemas significativos.
• TRR: Test Readiness Review (Preparación Prueba de Revisión): La TRR es una
evaluación para determinar si un sistema o componente está listo para ser sometido a
pruebas. Esta revisión asegura que todos los requisitos previos a la prueba se han
cumplido y que se dispone de los recursos, herramientas y documentación necesarios
para llevar a cabo las pruebas.
• FCA: Auditoría de la Configuración Funcional: La FCA es una auditoría que verifica
que el sistema o software desarrollado cumple con los requisitos funcionales
especificados. Se asegura de que cada función del sistema ha sido implementada y
funciona como se espera según las especificaciones.
• PCA: Auditoría de la Configuración Física: La PCA es una auditoría para verificar
que el sistema o componente físico se ha construido según las especificaciones
detalladas en los documentos de diseño. Se asegura de que todos los elementos físicos
del sistema cumplen con los requisitos técnicos y de diseño establecidos.
PROCESODEAUDITORIA
• La auditoría es la revisión y la evaluación de los controles, sistemas, procedimientos
de informática; así como de los recursos informáticos de una organización con el fin
de lograr una utilización más eficiente y segura de la información y de los recursos
informáticos para la adecuada toma de decisiones.
• La auditoría de software es un término general que se refiere a la investigación y al
proceso de pruebas que determina cómo se adquiere, distribuye y usa el software en
una organización.
• La auditoría deberá comprender no sólo la evaluación de los equipos de cómputo, de
un sistema o procedimientos específicos, sino que además habrá de evaluar los
sistemas de información en general desde sus entradas, procedimientos, controles,
archivos, seguridad y obtención de información.
Clase 7 – CONFIABILIDAD
Clase 8 –
Clase 9 – Evaluación de la Calidad y Métrica.