Tema 4 – Diseño y Realización de Pruebas

1.- Introducción

La mitad de esfuerzo de desarrollo de un programa, tanto en tiempo como en gastos, se va en la fase de pruebas. Es
una de las últimas fases del ciclo de vida antes de entregar el programa.

-Objetivos:

 Evitar plazos y presupuestos incumplidos

 Evitar insatisfacción del usuario y pérdida de clientes
 Evitar escaza productividad y mala calidad en el software producido
 Automatizar el proceso de pruebas (reducciones de hasta 75% en coste en mantenimiento)

La fase de pruebas añade valor al producto. Descubre los errores que tienen los programas -> Objetivo específico:
encontrar cuántas más errores mejor. Cuando se comprueba que el programa funciona bien, se pasa entonces a la
fase de pruebas.

Probar un programa: Proceso de ejecutar un programa con el fin de encontrar errores.

-Alcance (cobertura) de la prueba: Probar un programa es someterle a todas las posibles variaciones de los datos de
entrada, válidos o inválidos.

-Tipos de pruebas:

 En función del grado de conocimiento de código

 Pruebas de caja negra (Pruebas Funcionales): no se conoce la implementación del código, sólo la
interfaz. Se prueban distintos valores de E/S.

 Pruebas de caja blanca (Pruebas Estructurales): se conoce el código que se va a ejecutar y se pueden
definir las pruebas para que cubran todos los posibles caminos.

 Según el grado de automatización

 Pruebas manuales: Se hacen al programar o las ejecuta una persona con la documentación.

 Pruebas automáticas: Se usa un software para sistematizar las pruebas y obtener los resultados.

 En función de la fase del ciclo de vida en que se prueba

 Pruebas unitarias: Se aplican a un componente del software. Un componente puede ser una función,
una clase, librería, etc. (Generalmente es una clase)

 Pruebas de integración: Consiste en construir el sistema a partir de los distintos componentes y

probarlo con todos integrados. Se realizan progresivamente por etapas, añadiendo más módulos en
cada prueba.
 Prueban la semántica entre los diferentes módulos (estática y dinámica).
 Semántica estática: Se importan los módulos adecuados, se llama correctamente a los
procedimientos proporcionados por cada módulo.
 Semántica dinámica: Un módulo recibe de otro lo que esperaba.

 Pruebas funcionales: Sobre el sistema funcionando se comprueba que cumple con la especificación
(casos de uso).

ESTAS TRES PRUEBAS COMPRUEBAN LA EFICACIA DEL SISTEMA.

  Pruebas de rendimiento: Comprueban la eficiencia. Si el sistema soporta el volumen de carga
definido en la especificación.

 Pruebas de aceptación: Las únicas pruebas realizadas por los usuarios. Todas las anteriores las llevan
a cabo el equipo de desarrollo.
 Pruebas alfa: Las realiza el usuario en presencia del personal de desarrollo del proyecto
haciendo uso de una máquina preparada para tal fin.
 Pruebas beta: Las realiza el usuario después de que el equipo de desarrollo les entregue una
versión casi definitiva del producto.

Prueba Objetivo Realización

Unitarias Eficacia Equipo de desarrollo
Integración Eficacia Equipo de desarrollo
Funcionales Eficacia Equipo de desarrollo
Rendimiento Eficiencia Equipo de desarrollo
Aceptación x Usuario

-Conceptos:

 Completitud: Da una idea del grado de fiabilidad de las pruebas y del software. No se puede llegar al 100%.
 Depuración: Ejecución contralada del software que nos permite corregir un error.

-Otras pruebas:

 Regresión (regression testing): Cada nueva versión de un programa en la que se hayan modificado cosas, ya
sea corregir defectos o añadir funciones, han de pasar de nuevo por pruebas para comprobar que las
modificaciones no provocan errores donde antes no los había.

 Recorridos (walkthroughs): Técnica más aplicada en control de calidad que en pruebas.

o Se sientan alrededor de una mesa los desarrolladores y una serie de críticos, con un moderador. Los
revisores se leen el programa línea a línea y piden explicaciones de todo lo que no está claro.
o Para un sistema complejo pueden hacer falta varias sesiones.
o Es eficaz localizando errores de naturaleza local pero falla cuando el error proviene de la interacción
entre dos partes alejadas del programa (el programa no se está ejecutando, sino que se está
mirando línea a línea).

 Aleatorias (random testing): Se empieza la fase con una serie de casos elegidos al azar. Pondrá de manifiesto
los errores más patentes pero otros que se muestran ante entradas más precisas pueden estar ocultos.
o Si es un programa poco crítico como un videojuego o una app personal puede bastar pero en
aplicaciones militares o con riesgo de vida no.

 Aguante (stress testing): Hay algunos sistemas en los que es conveniente saber hasta dónde aguantan por
razones internas (cuántos datos procesa) o externas (capacidad de trabajar con x disco duro, aguante de
carga, etc.).
  Prestaciones (performance testing): Conocer cómo evolucionan ciertos parámetros al variar la dimensión del
problema (p. ej. al duplicarse el volumen de datos de entrada).
o Tiempo de respuesta, parámetros de gasto, consumo de memoria, espacio en disco utilizado, etc.

2.- Procedimientos y casos de prueba. Pruebas de código. Cubrimiento. Valores límite. Clases de equivalencia.

-Definición de caso de prueba: Conjunto formado por unas entradas, unas condiciones de ejecución y unos
resultados esperados.

 Objetivo: Realizar una prueba concreta del código.

o Por ejemplo: No deja entrar a un usuario existente con un password equivocado.
 Procedimiento de prueba: Pasos que hay que llevar a cabo para probar uno (o varios) casos de prueba.
o Un buen caso de prueba es aquel que tiene una posibilidad muy alta de descubrir un nuevo error. No
debe ser ni muy sencillo ni muy complejo, es mejor realizar cada prueba de forma separada si se
quiere probar diferentes casos.
o Una prueba tiene éxito si descubre un error.
o Para diseñar los casos de prueba -> Pruebas de caja blanca y pruebas de caja negra.

-Caja blanca (pruebas estructurales, caja transparente):

Aseguran que el código interno del programa se ajusta a las especificaciones y que todos los componentes internos
se han probado adecuadamente. Intenta garantizar que todos los caminos de ejecución quedan probados.

Siempre estamos observando el código con el ánimo de probarlo todo. Esta noción de prueba total se llama
“cobertura” y hay varias posibilidades de definirla.

 Cobertura de segmentos: Conocida como cobertura de sentencias.

o Segmento: Secuencia de sentencias sin puntos de decisión. El número de sentencias de un programa
es finito. Se puede diseñar un plan de pruebas que vaya ejercitando más y más sentencias hasta
llegar a la mayoría.
o En la práctica el proceso de pruebas termina antes de llegar al 100%.

 Cobertura de ramas: Se refina la cobertura de segmentos para que recorra todas las posibles salidas de los
puntos de decisión.
o Por ejemplo, en un IF, para conseguir cobertura del 100% hay que ejecutar al menos 2 veces, una
cumpliendo la condición y otra sin cumplirla (esto con la cobertura de segmentos no se cumple ya
que ejecutaría una vez cumpliendo la condición y ya consideraría una cobertura de 100%).
o También se aplica en el CASE.

 Cobertura de condición/decisión: Cuando las expresiones booleanas que se usan para decidir por qué rama
tirar son muy complejas se vuelve a refinar de nuevo.
o Por ejemplo, en un IF condición1 OR condición2, ambas condiciones pueden tomar 2 valores
distintos, lo que crea 4 combinaciones distintas, pero sólo hay 2 posibles ramas (true o false) que
con 2 pruebas sería suficiente para cubrirlas. Si hiciéramos esto, cerraríamos la puerta a otras
combinaciones.
o Con este refinamiento, se cubrirían las 4 combinaciones.

 Cobertura de bucles:
o Para WHILE hay que pasar 3 pruebas: 0 ejecuciones – 1 ejecución – más de 1 ejecución
 o Para DO-WHILE hay que pasar 2 pruebas: 1 ejecución – más de 1 ejecución
o Para FOR sólo necesitamos una ya que está definido el nº de veces que se va a ejecutar – Sólo hay
que ejecutarlos una vez.
 Aún así hay que examinarlo bien por si tuviera alguna “trampa” con posibles alteraciones
dentro del bucle de la variable de control o el valor de alguna variable que se use para
incrementar, o con sentencias EXIT o RETURN.

 Práctica: En la práctica del día a día se suele alcanzar una cobertura muy cercana al 100%. Es muy
recomendable conseguir una buena cobertura de ramas pero no suele hacer falta ir a por una cobertura de
decisiones atomizadas.
o Si el programa involucra vidas humanas (sanidad, centrales nucleares, etc.) se busca una cobertura
cerca del 99% y se presta atención a las decisiones atómicas.
o En aplicaciones militares se persiguen coberturas muy elevadas, por encima del 90%.

 Limitaciones: Estas pruebas nos convencen de que un programa hace bien lo que hace, pero no de que haga
lo que necesitamos.

-Caja negra (pruebas de caja opaca, pruebas funcionales, pruebas de E/S, pruebas inducidas por los datos):

 Introducción: Se centran en lo que se espera del módulo. El probador se limita a suministrarle datos como
entrada y estudiar la salida, sin preocuparse de lo que el módulo haga por dentro.
o Se apoyan en la especificación de requisitos del módulo. Se habla de “cobertura de especificación”
para dar una medida del número de requisitos que se han probado.
o Es fácil obtener coberturas del 100% en módulos internos, en externos es un poco más laborioso.
o Uno de los problemas es que el conjunto de datos posibles suele ser muy amplio.
o Técnica algebraica -> Clases de equivalencia: técnica que trata cada parámetro como un modelo
algebraico donde unos datos son equivalentes a otros, así se podría probar solo un caso de cada
clase (si conseguimos un rango de valores amplios).
 Problema: identificar clases de equivalencia.
 Si un parámetro de entrada debe estar entre un rango -> 3 clases de equivalencia
 Por debajo, en y por encima del rango.
 Si una entrada requiere un valor concreto -> 3 clases de equivalencia
 Por debajo, en y por encima del valor.
 Si una entrada requiere un valor de entre los de un conjunto -> 2 clases de equivalencia
 En el conjunto o fuera de él.
 Mismos criterios para salidas esperadas.

 Ejemplos: Una vez identificadas las clases de equivalencia significativas, se procede a coger un valor de cada
clase que no esté justamente al límite. Este valor aleatorio hará las veces de cualquier valor normal.
o Hay una serie de valores denominados “frontera” o valores límites que conviene probar además de
los anteriores (clases de equivalencia).
 Usualmente se necesitan 2 valores por frontera, uno justo abajo y otro justo encima
 Si la entrada se encuentra en el rango a…b -> Hay que probar con los valores a -1, a,
a+1, b-1, b, b+1.
 Si la entrada es un conjunto de valores -> max-1, max, max+1, min-1, min, min+1.
 Limitaciones: Nos convencen de que un programa hace lo que queremos, pero no de que haga (además)
otras cosas menos aceptables.
3.- Planificación de pruebas. Tipos de pruebas. Automatización de pruebas.

-Plan de pruebas: Está constituido por un conjunto de pruebas.

 Cada prueba debe especificar:

o Tipo de propiedades que se quieren probar (corrección, robustez, fiabilidad, etc.)
o Cómo se mide el resultado
o En qué consiste la prueba (hasta el último detalle de cómo se ejecuta)
o El resultado que se espera (identificación, tolerancia, etc.)

 Orden de pruebas:
o Caja negra analizando valores límite.
o Identificar clases de equivalencia de datos y añadir más pruebas de caja negra con valores normales.
o Añadir pruebas basadas en presunción de error.
o Cobertura de caja blanca y añadir más pruebas de caja blanca hasta lograr la cobertura deseada.

-Estrategias de aplicación de pruebas: Las pruebas comienzan a nivel de módulo, una vez terminadas progresan
hacia la integración del sistema completo y su instalación, y culminan cuando el cliente acepta el producto y se
explota.

Para ello se elabora un documento con el plan de pruebas.

 Objetivo: Señalar el enfoque, recursos y esquemas de actividades de prueba, y los elementos a probar,
características, actividades, personal responsable y riesgos asociados.
 Esquema de plan de pruebas:
 Identificador único del documento
 Introducción y resumen de elementos y características a probar
 Elementos software a probar
 Características a probar
 Características que no se probarán
 Enfoque general de la prueba
 Criterios de paso/fallo para cada elemento
 Criterios de suspensión y requisitos de reanudación
 Documentos a entregar
 Actividades de preparación y ejecución de pruebas
 Necesidades de entorno
 Responsabilidades en la organización y realización de pruebas
 Necesidades del personal y formación
 Esquema de tiempos
 Riesgos asumidos por el plan y planes de contingencias
 Aprobaciones y firmas con nombre y puesto desempeñado.

 Junto a este documento se pueden encontrar otros como:

 Documento de especificación del diseño de pruebas: Refinamientos necesarios sobre el enfoque
general del plan e identificación de características que se deben probar.
 Documento de especificación de caso de prueba: Define uno de los casos de pruebas identificado
por una especificación del diseño de pruebas.
  Documento de especificación de procedimiento de prueba: Especifica los pasos para la ejecución del
conjunto de casos de prueba.

A. Prueba de unidad: Una unidad de prueba es uno o más módulos que cumples las siguientes condiciones:
 Todos son del mismo programa
 Al menos uno de ellos no ha sido probado
 El conjunto de módulo es el objeto de un proceso de prueba

Son las pruebas formales que permiten declarar que un módulo está listo y terminado. Especialmente orientado
a pruebas de caja blanca completándose con caja negra. Se prueban los caminos de control para descubrir
errores en los límites del módulo y se puede realizar paralelamente en varios módulos.

B. Prueba de integración: Los módulos probados se integran para comprobar el conjunto.

 Implican una progresión ordenada de pruebas que van desde los componentes y que culminan en el
sistema completo.

 El orden de integración afecta a diversos factores como: forma de preparar casos, herramientas
necesarias, orden de codificar y probar, y el coste de la depuración y preparación de casos.

 Tipos fundamentales de integración:

 Integración incremental: Se combina el siguiente módulo que se debe probar con el conjunto de
módulos ya probados.
 Ascendente: Se comienza por los módulos hoja.
 Descendente: Se comienza por el módulo raíz.
 Integración no incremental: Se prueba cada módulo por separado y luego se integran todos ade
una vez y se prueba el programa completo.

Habitualmente las pruebas de unidad y de integración se solapan y se mezclan. Con los nuevos módulos
añadidos el software cambia y es posible que haya problemas con funciones que antes iban bien. Se ejecutará un
conjunto de pruebas ya realizado anteriormente para asegurarse de que los cambios no han cambiado otras
cosas (pruebas de regresión).

C. Prueba validación: El software totalmente ensamblado se prueba como un conjunto para ver si cumple o no los
requisitos funcionales (rendimiento, seguridad, etc.).
 Se realiza después de las de integración. La validación se consigue cuando funciona según las
expectativas del usuario.
 Generalmente son pruebas de caja negra.

D. Prueba sistema: Software ya validado se integra con el resto de sistema (elementos mecánicos, interfaces
electrónicas, etc.) para probar el funcionamiento.
 Se efectúan sobre procesos que afectan a la seguridad en el acceso de datos, rendimiento bajo
condiciones de grandes cargas de trabajo, tolerancia a fallos y recuperación del sistema.
 Condiciones límite y de sobrecarga.
 Verifican que se han integrado adecuadamente todos los elementos del sistema y que se realizan las
funciones apropiadas.

E. Prueba aceptación: El producto final es comprobado por el usuario en su propio entorno de explotación para ver
si lo acepta como está o no.
 Es la fase final del proceso para crear una confianza en que el producto es apropiado para su uso.
-Automatización de pruebas: Consiste en el uso de software especial para controlar la ejecución de pruebas y la
comparación entre los resultados obtenidos y los resultados esperados.

 Permite incluir pruebas repetitivas y necesarias dentro de un proceso ya existente o añadir pruebas cuya
ejecución manual es difícil.
 Una prueba automatizada puede ejecutarse repetitiva y rápidamente en particular con productos de
software con ciclos de mantenimiento largo. (Por ejemplo: pruebas de regresión intensivas)

 Existen 2 aproximaciones a las pruebas automatizadas:

o Pruebas manejadas por el código: Se prueban las interfaces públicas de las clases, módulos o
bibliotecas con una variedad amplia de argumentos de entrada y se valida que los resultados
obtenidos sean los esperados.
 Se realizan a través de herramientas específicas de los IDEs (JUnit, Visual Studio, etc.).
Permiten la ejecución de pruebas unitarias para determinar si secciones del código tienen el
comportamiento esperado en condiciones específicas o no.

o Pruebas de Interfaz de Usuario: Un marco de pruebas genera un conjunto de evento de la interfaz de

usuario (teclear, hacer clic, etc.) y se observan los cambios resultantes en la interfaz de usuario,
validando que el comportamiento observable del programa sea correcto.

La decisión entre manual y automatización, herramientas utilizadas, componentes, etc. Tiene que ser una decisión
conjunto de los equipos de desarrollo, control de calidad y administración.