Al finalizar esta unidad podrás

Antes de empezar

Si un campo acepta días de préstamo del 1 al 14, ¿qué tres valores usarías para probarlo?

¿Quién debería probar la función que calcula una multa: quien la programó, otra persona del equipo o quien usará el sistema?

Abre tus escenarios (ESC) de la Unidad II: ¿alguno indica valores concretos? ¿Cómo los eligieron?

Una situación

Nadie puede decir qué valores se usaron, por qué esos, qué partes del código se ejecutaron, qué se probó primero ni cuándo se decidió que era suficiente.

Caso ilustrativo ficticio, común para todo el grupo. Tu sistema bajo prueba es tu proyecto base (A, B o C).

Las reglas del SPB

También: RF-01 registrar préstamo · RF-02 registrar devolución y calcular multa · RF-03 buscar libro.

Pregunta orientadora

Lo que ya tienes

Mapa de la unidad

Nivel de prueba y tipo de prueba

Los cuatro niveles

Base de prueba: el documento del que salen los casos y sus resultados esperados.

Nivel unitario: el componente aislado

FUNCIÓN calcularMulta(diasRetraso, tipoUsuario)
1   SI diasRetraso <= 0 ENTONCES RETORNAR 0 ...
4   tarifa ← 5
5   SI tipoUsuario = "DOCENTE" ENTONCES tarifa ← 3 ...
8   multa ← diasRetraso * tarifa
9   SI multa > 100 ENTONCES multa ← 100 ...
12  RETORNAR multa

CASO (unitario)   Entrada: diasRetraso = 3, tipoUsuario = "ESTUDIANTE"
                  Resultado esperado: 15     (RN-04: 3 × 5 MXN)

Si falla, el defecto solo puede estar dentro de calcularMulta.

Nivel de integración: el acuerdo entre componentes

FUNCIÓN registrarDevolucion(idPrestamo, fechaDevolucion)
1   prestamo ← repositorioPrestamos.buscar(idPrestamo)
2   usuario  ← servicioUsuarios.obtener(prestamo.idUsuario)
3   diasRetraso ← diasEntre(prestamo.fechaLimite, fechaDevolucion)
4   multa ← calcularMulta(diasRetraso, usuario.tipo)
5   prestamo.multa ← multa
6   repositorioPrestamos.guardar(prestamo)

Sistema y aceptación

Los criterios dado–cuando–entonces de la Unidad II son la base de la prueba de aceptación.

Una misma regla, cuatro niveles

Niveles y ciclo de vida: el modelo en V

Requisitos del negocio ─────────────────────── Prueba de aceptación
    Requisitos del sistema ─────────────── Prueba de sistema
        Diseño de arquitectura ─────── Prueba de integración
            Diseño detallado ────── Prueba unitaria
                      Implementación

Los casos de cada nivel pueden diseñarse en cuanto existe su base de prueba, aunque se ejecuten después (pruebas tempranas, Unidad I).

Por eso puedes diseñar casos para tu proyecto base aunque todavía no sea ejecutable.

Integración: ¿todo junto o poco a poco?

En la Unidad IV verás cómo se simulan los componentes que aún no existen.

Actividad A1 — Clasificación de niveles

Producto: tabla de clasificación justificada por el objeto de prueba.

Instrucciones completas: Actividades de la Unidad 03, Actividad A1.

¿Qué es una técnica de diseño de pruebas?

Un procedimiento sistemático para decidir qué casos escribir y con qué datos, de forma que la elección se pueda justificar, repetir y revisar.

Las pruebas basadas en riesgos deciden cuánto esfuerzo y qué técnicas asignar a cada parte.

Los enfoques se complementan

Entre negra y blanca está la caja gris: conocimiento parcial del diseño, ejecución por la interfaz externa (Bloque 4).

Del escenario al caso de prueba

ESC (Unidad II)                    técnica (Unidad III)            CP (Unidad III)
"Préstamo con días fuera      →    valores límite          →      CP: días = 15 → rechazado
 del rango permitido"              sobre RN-01                     CP: días = 0  → rechazado

Formato del caso de prueba

Actividad A2 — Selección de enfoque

Instrucciones completas: Actividades de la Unidad 03, Actividad A2.

Partición de equivalencia: ¿qué problema resuelve?

RN-01 acepta 1 a 14, pero el campo puede recibir cualquier cosa: -1 000, 0, 7, 15, 2.5, "abc", vacío.

Las pruebas exhaustivas no existen (Unidad I): hay que elegir bien.

Partición de equivalencia: qué es

Divide el dominio de una entrada (o salida) en clases: grupos que el sistema debe tratar igual.

• Cobertura del dominio: todo valor cae en alguna clase.
• Sin traslape: ningún valor cae en dos clases.
• Válidas (la regla las acepta) e inválidas (fuera de rango, tipo incorrecto, vacío).

¿Cómo encuentro las clases?

Reglas prácticas de Myers et al. (REF-U3-01). Si sospechas que valores de una clase se tratan distinto, divídela.

Ejemplo — RN-01 (días de préstamo, 1 a 14)

Dos reglas que evitan errores

Particiones de salida — RN-04

Variantes: débil o fuerte, normal o robusta

La débil supone que los defectos dependen de una sola entrada. Si el resultado depende de cómo se combinan, usa la fuerte o una tabla de decisión (Jorgensen, REF-U3-02).

Cuando el supuesto falla

FUNCIÓN validarDias(dias)
1   SI dias < 1 ENTONCES RETORNAR "RECHAZADO"
4   SI dias > 10 ENTONCES RETORNAR "REQUIERE AUTORIZACIÓN"   ← no está en RN-01
7   SI dias > 14 ENTONCES RETORNAR "RECHAZADO"
10  RETORNAR "ACEPTADO"

Análisis de valores límite: ¿qué problema resuelve?

"Entre 1 y 14 inclusive" se traduce a <, <=, >, >=. Un símbolo mal escrito cambia el comportamiento solo en los bordes.

Solo aplica a clases ordenadas: números, fechas, horas, cantidades, longitudes.

Los defectos viven en los bordes

Variantes de valores límite

Ejemplo genérico: "hasta 10 MB" programado como tamaño = 10. Con 10 y 11 no se detecta. Con 9 sí.

Con varias entradas: normal 4n + 1, robusto 6n + 1, peor caso 5ⁿ (Jorgensen, REF-U3-02).

Tablas de decisión: ¿qué problema resuelven?

Estructura de una tabla de decisión

                         │ R1 │ R2 │ R3 │ R4 │   ← reglas: una combinación cada una
─────────────────────────┼────┼────┼────┼────┤
 C1: compra ≥ 500 MXN    │ S  │ S  │ N  │ N  │   ← condiciones
 C2: cliente registrado  │ S  │ N  │ S  │ N  │
─────────────────────────┼────┼────┼────┼────┤
 A1: envío gratuito      │ X  │    │    │    │   ← acciones
 A2: cobrar envío        │    │ X  │ X  │ X  │

n condiciones Sí/No → 2ⁿ reglas. Llenado sistemático: la primera condición alterna cada 2ⁿ⁻¹ columnas. La última, en cada columna.

Por qué no basta "un caso bueno y uno malo"

Correcto:   SI montoCompra >= 500 Y registrado ENTONCES "GRATUITO"
Defecto:    SI montoCompra >= 500 O registrado ENTONCES "GRATUITO"

Reducir y comprobar

Si una condición no cambia las acciones, se marca con — y las columnas se fusionan: R3 y R4 → (N, —).

Entrada extendida y combinaciones imposibles

La tabla también es una herramienta de análisis

Con muchas condiciones la tabla crece (6 condiciones → 64 reglas): reduce cuando se justifique, separa en subreglas o prioriza por riesgo.

¿Qué técnica de caja negra elijo?

En los proyectos base: cantidad frente a existencia (B), cupo (C) y horario dentro de la disponibilidad (A). Por ejemplo: solicitar cita, generar pedido, inscribirse.

Relación con el Laboratorio 01

Caja blanca: ¿qué problema resuelve?

Veinte casos de caja negra bien diseñados pueden dejar una rama completa del código sin ejecutar. Lo que no se ejecuta, no se prueba.

En pseudocódigo (D-005). En la Unidad IV medirás la cobertura con herramientas.

Familia de técnicas de caja blanca

"Camino básico" en algunos textos: el original es basis path, camino base.

El grafo de flujo de control

Patrones de traducción

La arista F de un SI sin SINO va directo a la unión: es la que más se olvida.

Ejemplo — validarDias

1  SI dias < 1 ENTONCES
2      RETORNAR "RECHAZADO"
3  FIN SI
4  SI dias > 14 ENTONCES
5      RETORNAR "RECHAZADO"
6  FIN SI
7  RETORNAR "ACEPTADO"

     [1] dias < 1 ?
     /V          \F
  [2] RECHAZADO   [4] dias > 14 ?
                  /V          \F
           [5] RECHAZADO    [7] ACEPTADO

Rutas: 1(V)→2 · 1(F)→4(V)→5 · 1(F)→4(F)→7

¿Por qué no probar todas las rutas?

Rutas linealmente independientes

Una ruta es independiente si recorre al menos una arista nueva. V-V no aporta aristas nuevas.

Complejidad ciclomática V(G)

• Número de casos que exige la prueba de rutas base.
• Máximo de casos para cubrir instrucciones y decisiones.
• Indicador de complejidad: a mayor V(G), más difícil de probar y mantener.

McCabe sugirió revisar módulos con V(G) mayor que 10 (PENDIENTE DE VERIFICACIÓN del valor en la fuente).

Tres formas de calcularla

Condiciones compuestas

1  SI dias < 1 O dias > 14 ENTONCES
2      RETORNAR "RECHAZADO"
3  FIN SI
4  RETORNAR "ACEPTADO"

Prueba de rutas base

1. Dibuja el grafo. 2. Calcula V(G) por dos métodos. 3. Construye la base: cada ruta nueva cambia una decisión. 4. Elige datos que fuercen cada ruta. 5. Resultado esperado desde la especificación.

Especificación: base 50 MXN, más de 5 kg suma 30 y exprés duplica el costo.

Cobertura de instrucciones

1  SI edad >= 18 ENTONCES
2      RETORNAR "ADULTO"
3  SINO SI edad >= 21 ENTONCES
4      RETORNAR "ADULTO MAYOR DE 21"
5  FIN SI
6  RETORNAR "MENOR"

Instrucciones no basta

// Socios: 10 % de descuento
1  descuento ← 10     // debía ser 0
2  SI esSocio ENTONCES
3      descuento ← total * 0.10
4  FIN SI
5  RETORNAR total - descuento

Cobertura de decisiones (ramas)

Exige: que cada decisión tome V y F. En el grafo, recorrer cada arista de decisión. Prueba la arista F "invisible" del SI sin SINO.

1  SEGÚN tipo HACER
2    "ESTUDIANTE": RETORNAR 5
3    "DOCENTE":    RETORNAR 3
4    OTRO:         RETORNAR 5
5  FIN SEGÚN

Cobertura de condiciones

SI activo O claveCorrecta — defecto: debía ser Y.

Cobertura de condiciones: cada condición simple toma V y F al menos una vez.

Cuatro criterios sobre la misma decisión

Cobertura de todas las rutas

D1: costo ← costo + 80 · D2: costo ← 50 * 2 (línea 6 de calcularPrecioEnvio)

¿Qué conjunto detecta cada defecto?

Resumen de criterios

"Incluye a": cumplir la fila implica cumplir lo indicado. Ningún criterio garantiza encontrar todos los defectos.

Prueba de ciclos: ciclo simple

Probar 0, 1, 2 y un número típico de vueltas. Si el ciclo se detiene una vuelta antes, el último préstamo nunca se revisa: el caso de una vuelta lo revela.

Ciclo con máximo

Ciclos anidados y concatenados

Flujo de datos: conceptos

Los criterios anteriores miran por dónde pasa la ejecución. El flujo de datos mira si cada valor llega a donde se usa (REF-U3-02).

costo ← costo + 30 es a la vez uso y nueva definición.

Pares du de costo

D2 (costo ← 50 * 2) rompe el par def 3 → uso 6, que ninguna ruta de B1–B3 recorre.

Criterios de flujo de datos

Anomalías de flujo de datos

// Suma de adeudos + recargo de 15
1  recargo ← 10
2  i ← 1
3  MIENTRAS i <= longitud(adeudos)
4      total ← total + adeudos[i]
5      i ← i + 1
6  FIN MIENTRAS
7  recargo ← 15
8  RETORNAR total

Análisis estático de código

Se agrupa con la caja blanca porque necesita el código, pero se clasifica como prueba estática: no diseña casos (REF-U3-04, REF-U3-19).

Qué detecta el análisis estático

Límites de la caja blanca

Caja gris: entre los dos enfoques

Complemento de 3.2.1–3.2.2. No es un tema propio del programa. Se usa más en integración y sistema.

Caja gris: ejemplos (SPB)

Los datos de diseño son supuestos académicos.

Negra, gris y blanca

En los tres, el resultado esperado sale de la especificación. En las Unidades IV y V aplicarás la caja gris a bases de datos y APIs.

Relación con el Laboratorio 02

Pruebas exploratorias: ¿qué problema resuelven?

Las técnicas anteriores solo prueban lo que alguien anticipó. Muchos problemas aparecen en situaciones que nadie escribió: secuencias raras, interrupciones, datos extraños.

Prueba con guion  ◄────────────────────────────►  Prueba exploratoria
(casos escritos antes)                            (diseñar, ejecutar y aprender a la vez)

¿Qué es un charter?

Estructura del charter

Explorar       el registro de devoluciones
con            fechas de entrega cercanas a fin de mes y ambos tipos de usuario
para descubrir errores en el cálculo de los días de retraso y de la multa

Formato explorar–con–para descubrir propuesto por Hendrickson (REF-U3-18, PENDIENTE DE VERIFICACIÓN).

Buenos y malos charters

Fuentes de charters: matriz de riesgo, escenarios negativos y de límite, preguntas abiertas de las tablas de decisión, hallazgos previos.

La sesión exploratoria

Gestión basada en sesiones (Bach, REF-U3-17, PENDIENTE DE VERIFICACIÓN). Hoja de sesión: charter, personas, tiempo, ambiente, notas, posibles defectos, preguntas, datos, oportunidades, cierre.

Ejemplo de notas de sesión (SPB)

Las notas registran también lo que funcionó: es información de cobertura.

Pruebas basadas en riesgos

Usan el riesgo de producto para decidir qué probar primero, con qué técnicas, en qué niveles y con cuánta profundidad.

Proceso: identificar → analizar → priorizar y tratar → monitorear. Escala: 1 bajo, 2 medio, 3 alto (en la Unidad I: alto/medio/bajo).

Del riesgo al tratamiento

Escala: 6–9 alto, 3–4 medio, 1–2 bajo.

Actividad A3 — Riesgo y exploración

Instrucciones completas: Actividades de la Unidad 03, Actividad A3.

¿Qué es un plan de pruebas?

El documento que dice antes de ejecutar qué se prueba, qué no, cómo, con qué, quién, cuándo empieza y cuándo termina.

Es un documento vivo: cambia con los requisitos, los riesgos y el calendario, y cada cambio se registra.

¿Qué responde un plan de pruebas?

Objetivo y alcance

Estrategia de pruebas

Criterios de entrada y salida

Suspensión: cuándo detener porque continuar no informa nada. Reanudación: cuándo retomar.

Datos y ambientes de prueba

Riesgo de producto y riesgo de prueba

Fuentes de riesgos de prueba: personas, ambiente, requisitos ambiguos, tiempo, herramientas.

El formato del plan de pruebas de la materia

Explicación de cada sección y plantilla: Formato del Plan de Pruebas — Unidad 03. Simplificación didáctica inspirada en los estándares.

Actividad A4 — Estrategia y criterios del SPB

Es un ensayo sobre el caso común antes del plan de tu proyecto base.

Instrucciones completas: Actividades de la Unidad 03, Actividad A4.

Estándares de referencia

Un estándar se usa como referencia y vocabulario común, no se "aplica completo" en un proyecto académico.

Documentos de prueba

La denominación exacta varía entre normas y ediciones.

Evidencias de ejecución

Una evidencia útil responde, sin preguntarle a nadie:

Una captura sin ID, fecha ni resultado esperado no es evidencia: es una imagen.

Relación con el Laboratorio 03 — evidencia oficial

Criterios de desempeño: Rúbrica de la Unidad 03.

Cierre — volviendo al SPB

• Nivel: la multa se prueba como función, en su conversación con otros componentes, en pantalla y con la persona bibliotecaria.
• Técnica: partición y valores límite para RN-01 y RN-02, tabla de decisión para RN-03, particiones de salida y caja blanca para RN-04, y charter para la búsqueda.
• Orden: primero RN-03 y RN-04, por su riesgo alto.
• Terminar: cuando se cumplan criterios de salida escritos antes de empezar.
• Demostrar: con casos documentados y evidencias revisables.

En síntesis

• Niveles por objeto de prueba. Tipos por característica evaluada.
• Un caso concreta un escenario con datos, técnica y oráculo.
• Partición evita repetir esfuerzo. Valores límite atrapan los bordes. Tablas de decisión cubren combinaciones y revelan huecos.
• Grafo, rutas base y V(G) guían la cobertura de la lógica. Ciclos y flujo de datos la completan. Ninguna cobertura garantiza encontrar todo.
• El análisis estático encuentra defectos sin ejecutar. La caja gris usa lo que se sabe del diseño.
• Charter y sesión para explorar. Riesgo para priorizar.
• El plan fija qué, cómo, con qué, cuándo empezar y cuándo terminar.

Lo que sigue

En la Unidad IV vas a escribir y ejecutar pruebas unitarias y de integración automatizadas, a partir de casos como los que diseñaste en esta unidad.

Referencias

• Myers, Sandler y Badgett — The Art of Software Testing (3.ª ed., 2011).
• Jorgensen — Software Testing: A Craftsman's Approach (4.ª ed., 2013).
• Patton — Software Testing (2.ª ed., 2005).
• Black, van Veenendaal y Graham — Foundations of Software Testing ISTQB Certification (2012).
• Crispin y Gregory — Agile Testing (2009).
• ISO/IEC/IEEE 29119 (Partes 1 a 4), IEEE 829-2008 e ISO/IEC 25010.
• Complementarias (PENDIENTE DE VERIFICACIÓN): McCabe (1976), Watson y McCabe (1996), Bach (2000), Hendrickson (2013) e ISTQB CTFL v4.0 (2023).

Ficha completa de cada fuente: unidad03/referencias/unidad03_materiales_referencias.md (REF-U3-01 a REF-U3-19).