UNIDAD 3

METODOS DE PRUEBA DEL SOFTWARE

1 Fundamentos de la prueba del software
1 Diseño de casos de prueba
2 Métodos de caja blanca
2 Prueba del camino básico
2 Prueba de la estructura de control
3 Prueba de caja negra
3 Partición equivalente
3 Análisis de valores limite

DEFINICION
 Elemento crítico para la garantía de la calidad del software y representa una revisión
final de las especificaciones del diseño y codificación.
 Es el proceso de ejecución de un programa con la intención de descubrir un error.
FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE
Aunque los desarrolladores de software son gente constructiva podríamos suponer a la PS.
Como destructiva, porque requiere que se descarten ideas preconcebidas sobre la corrección del
software que se acaba de desarrollar y se supere cualquier conflicto de intereses que aparezcan
cuando se descubran errores.
Beizer (BEI90,pag. 1) lo plantea de mejor manera diciendo: existe un mito que dice que si
fuéramos buenos programando, no habría errores que buscar. Claro está que como les he
dicho antes. No nos concentremos en buscar culpables,
LOS OBJETIVOS SEGÚN GLEN MYERS [MYE79]
1. La prueba es un proceso de ejecución de un programa con la intensión de descubrir un
error.
2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no
descubierto hasta entonces.
3. Una prueba tiene éxito si descubre un error no detectado hasta entonces.
Lo anterior significa que estábamos errados al pensar que una prueba fue satisfactoria sino
arrojo errores, al contrario la prueba no puede asegurar la ausencia de defectos, solo puede
demostrar que existen defectos en el software.
PRINCIPIOS DE LA PRUEBA DE SOFTWARE
Davis [DAV95] nos arroja un alud de principios de prueba que adaptaremos para usar en este
curso de Evaluación.
 A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos del
cliente.
 Las pruebas deberían planificarse mucho antes de que empiecen
  El principio de PARETO es aplicable a la prueba del software
 Las pruebas deberían empezar por << lo pequeño>> y progresar hacia << lo grande>>
 No son posibles las pruebas exhaustivas.
 Para ser más efectivas, las pruebas deberían ser conducidas por un equipo
independiente.
FACILIDAD DE PRUEBA
A continuación una lista de comprobaciones que sugieren un conjunto de características que
llevan a un software fácil de probar.
 OPERATIVIDAD: "cuanto mejor funcione, más eficientemente se puede probar"
 OBSERVABILIDAD: "Lo que ves es lo que pruebas"
 CONTROLABILIDAD: "Cuanto mejor podamos controlar el software, más se puede
automatizar y optimizar"
 CAPACIDAD DE DESCOMPOSICION: "Controlando el ámbito de las pruebas,
podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de
regresión"
 SIMPLICIDAD: "Cuanto menos haya que probar, más rápidamente podremos probarlo"
 ESTABILIDAD: "Cuanto menos cambios, menos interrupciones a la pruebas"
 FACILIDAD DE COMPRENSION: "Cuanta más información tengamos, más
inteligentes serán las pruebas"

DISEÑO DE CASOS DE PRUEBA

Un caso de prueba o test case es, en ingeniería del software, un conjunto de condiciones o
variables bajo las cuales un analista determinará si una aplicación, un sistema software
(software system), o una característica de éstos es parcial o completamente satisfactoria.
Se pueden realizar muchos casos de prueba para determinar que un requisito es completamente
satisfactorio. Con el propósito de comprobar que todos los requisitos de una aplicación son
revisados, debe haber al menos un caso de prueba para cada requisito a menos que un requisito
tenga requisitos secundarios. En ese caso, cada requisito secundario deberá tener por lo menos
un caso de prueba. Algunas metodologías como RUP recomiendan el crear por lo menos dos
casos de prueba para cada requisito. Uno de ellos debe realizar la prueba positiva de los
requisitos y el otro debe realizar la prueba negativa.
Si la aplicación es creada sin requisitos formales, entonces los casos de prueba se escriben
basados en la operación normal de programas de una clase similar.
Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada conocida y una
salida esperada, los cuales son formulados antes de que se ejecute la prueba. La entrada
conocida debe probar una precondición y la salida esperada debe probar una post condición.
Bajo circunstancias especiales, podría haber la necesidad de ejecutar la prueba, producir
resultados, y luego un equipo de expertos evaluaría si los resultados se pueden considerar como
"correctos". Esto sucede a menudo en la determinación del número del rendimiento de
productos nuevos. La primera prueba se toma como línea base para los subsecuentes ciclos de
pruebas/lanzamiento del producto.
Los casos de prueba escritos, incluyen una descripción de la funcionalidad que se probará, la
cual es tomada ya sea de los requisitos o de los casos de uso, y la preparación requerida para
asegurarse de que la prueba pueda ser dirigida.
Los casos de prueba escritos se recogen generalmente en una suite de pruebas.
Las variaciones de los casos de prueba son comúnmente utilizadas en pruebas de aceptación. La
prueba de aceptación es realizada por un grupo de usuarios finales o los clientes del sistema,
para asegurarse que el sistema desarrollado cumple sus requisitos. La prueba de aceptación de
usuario se distingue generalmente por la incorporación de un trayecto feliz o casos de prueba
positivos.
METODOS DE CAJA BLANCA
En programación, se denomina cajas blancas a un tipo de pruebas de software que se realiza
sobre las funciones internas de un módulo. Así como las pruebas de caja negra ejercitan los
requisitos funcionales desde el exterior del módulo, las de caja blanca están dirigidas a las
funciones internas. Entre las técnicas usadas se encuentran; la cobertura de caminos (pruebas
que hagan que se recorran todos los posibles caminos de ejecución), pruebas sobre las
expresiones lógico-aritméticas, pruebas de camino de datos (definición-uso de variables),
comprobación de bucles (se verifican los bucles para 0,1 e interacciones, y luego para las
interacciones máximas, máximas menos uno y más uno).
Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo concreto, para
luego realizar las de caja negra sobre varios subsistemas (integración).
En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los métodos
de la clase, pero según varias opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas
más especializadas (un argumento podría ser que los métodos de una clase suelen ser menos
complejos que los de una función de programación estructurada). Dentro de las Pruebas de Caja
Blanca encontramos las llamadas coberturas (sentencia, decisión, condición y múltiple además
de los mencionados caminos ciclomáticos propuestos por McCabe)
PRUEBAS DE CAJA BLANCA
Las pruebas de caja blanca (también conocidas como pruebas de caja de cristal o pruebas
estructurales) se centran en los detalles procedimentales del software, por lo que su diseño está
fuertemente ligado al código fuente. El ingeniero de pruebas escoge distintos valores de entrada
para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se
devuelven los valores de salida adecuados.
Al estar basadas en una implementación concreta, si esta se modifica, por regla general las
pruebas también deberán rediseñarse.
Aunque las pruebas de caja blanca son aplicables a varios niveles —unidad, integración y
sistema—, habitualmente se aplican a las unidades de software. Su cometido es comprobar los
flujos de ejecución dentro de cada unidad (función, clase, módulo, etc.) pero también pueden
probar los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las
pruebas de sistema.
A pesar de que este enfoque permite diseñar pruebas que cubran una amplia variedad de casos
de prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes,
pese a garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado.
Las principales técnicas de diseño de pruebas de caja blanca son:
 Pruebas de flujo de control
 Pruebas de flujo de datos
 Pruebas de bifurcación (branch testing)
 Pruebas de caminos básicos
PRUEBA DEL CAMINO BÁSICO
 Es una técnica de prueba de caja blanca propuesta inicialmente por Tom McCabe. El
método del camino básico permite al diseñador de casos de prueba obtener una medida
de la complejidad lógica de un diseño procedimental y usar esa medida como guía para
la definición de un conjunto básico de caminos de ejecución.
 Los casos de prueba obtenidos del conjunto básico garantizan que durante la prueba se
ejecuta por lo menos una vez cada sentencia del programa.
NOTACIÓN DE GRAFO DE FLUJO
Antes de considerar el método del camino básico se debe introducir una sencilla notación para
la representación del flujo de control, denominada grafo de flujo. El grafo de flujo representa el
flujo de control lógico.
Un ejemplo para definir los caminos de complejidad ciclo matica de 4 para la prueba del camino
básico.
Los caminos resultantes serian

PRUEBA DE LA ESTRUCTURA DE CONTROL

1.- Prueba de condición Se centra en la prueba de cada una de las condiciones del programa y
tiene como propósito detectar los errores en las condiciones de un programa y los errores del
programa.
2. Prueba del flujo de datos Se centra en la selección de caminos de prueba de un programa de
acuerdo con la ubicación de las definiciones y los usos de las variables del programa. Esta
prueba es útil para seleccionar caminos de prueba de un programa que contenga sentencias if o
bucles anidados.
3. Prueba de bucles Se centra en la validez de las construcciones de bucles. Se definen los
siguientes tipos de bucles:

PRUEBA DE CAJA NEGRA

Las pruebas de caja negra, es una técnica de pruebas de software en la cual la funcionalidad se
verifica sin tomar en cuenta la estructura interna de código, detalles de implementación o
escenarios de ejecución internos en el software.
En las pruebas de caja negra, nos enfocamos solamente en las entradas y salidas del sistema, sin
preocuparnos en tener conocimiento de la estructura interna del programa de software. Para
obtener el detalle de cuáles deben ser esas entradas y salidas, nos basamos únicamente en los
requerimientos de software y especificaciones funcionales.
En este artículo, te presentamos ejemplos de cómo definir pruebas de caja negra, para esto,
usaremos casos tanto de requerimientos funcionales y como no funcionales de software.
PMOInformatica presenta: Ejemplos de pruebas de caja negra.
LAS TÉCNICAS DE PRUEBAS DE CAJA NEGRA
Tal como vimos en nuestro artículo sobre la definición de pruebas de caja negra según el
ISTQB, existen distintas técnicas para realizar pruebas de caja negra de software, te sugerimos
revisar el artículo para obtener información general sobre que son las pruebas de caja negra.
> Las pruebas de caja negra según el ISTQB
Al estar basadas en los requerimientos de software y en las entradas y salidas de cada
funcionalidad, al definir una prueba de caja negra lo principal es identificar los datos de prueba
(entradas) y el resultado esperado del sistema al ingresar esos datos, bien sean los datos de
salida o algún comportamiento específico.
FORMATO PARA EL REGISTRO DE LOS CASOS DE PRUEBA
Los ejemplos de pruebas de caja negra que presentamos, siguen el formato de nuestra plantilla
para el diseño de casos de prueba, que puedes descargar en el siguiente enlace:
> Plantilla de casos de prueba
Ejemplos de pruebas de caja negra
A continuación enumeramos los ejemplos, presentando para cada uno los datos de entrada y
resultado esperado.
Ejemplo 1: Envió de correo electrónico al registrarse una transacción
Descripción del caso: El sistema enviará un correo electrónico cuando se registre alguna de las
siguientes transacciones: pedido de venta de cliente, despacho de mercancía al cliente, emisión
de factura a cliente y registro de cobro al cliente.
Técnica de pruebas de caja negra: Requerimiento funcional / Caso de uso
Caso 1.1: Datos de entrada: Registrar pedido de venta. Resultado esperado (Salida): El sistema
envía un correo electrónico al cliente como constancia que su pedido se ha recibido.
Caso 1.2: Datos de entrada: Registrar despacho de mercancía al cliente. Resultado esperado
(Salida): El sistema envía un correo electrónico al cliente como constancia que se ha realizado
el despacho.
Caso 1.3: Datos de entrada: Registrar factura de cliente. Resultado esperado (Salida): El sistema
envía un correo electrónico al departamento de facturación y al cliente.
Caso 1.4: Datos de entrada: Registrar cobro. Resultado esperado (Salida): El sistema envía un
correo electrónico al departamento de cuentas por cobrar y al agente comercial (vendedor) que
lleva la cuenta del cliente.
Ejemplo 2: Campo de texto que solo acepta caracteres alfabéticos
Descripción del caso: Se tiene un campo de texto que solo acepta caracteres alfabéticos. La
longitud del valor ingresado debe estar entre 6 y 10 caracteres.
Técnica de pruebas de caja negra: Partición de equivalencias.
Usando partición de equivalencias, se pueden establecer tres particiones, longitudes entre 0 y 5
caracteres (partición inválida), longitudes entre 6 y 10 caracteres (partición válida), y longitudes
mayores a 10 caracteres (partición inválida). Además, el ingreso de caracteres no alfabéticos
(por ejemplo un número), se considera también dato inválido.
Caso 3.1: Datos de entrada: cadena de 5 caracteres. Resultado esperado (Salida): La aplicación
no permite el ingreso del dato y muestra un mensaje de error.
Caso 3.2: Datos de entrada: cadena de 7 caracteres, incluyendo uno o más caracteres no
alfabéticos. Resultado esperado (Salida): La aplicación no permite el ingreso del dato y muestra
un mensaje de error.
Caso 3.3: Datos de entrada: cadena de 7 caracteres, solo de caracteres alfabéticos. Resultado
esperado (Salida): La aplicación permite el ingreso del dato.
Caso 3.4: Datos de entrada: cadena de 11 caracteres. Resultado esperado (Salida): La aplicación
no permite el ingreso del dato y muestra un mensaje de error.
PARTICIÓN EQUIVALENTE
La partición equivalente es un método que divide el campo de entrada de un programa en clases
de datos.
 Una condición de entrada es un valor numérico específico, un rango de valores, un
miembro de un conjunto de valores o lógica
 Una clase de equivalencia representa un conjunto de estados válidos y no válidos para
una condición de entrada.
 La prueba de partición equivalente se basa en evaluar las clases de equivalencia para
una condición de entrada.
Partición Equivalente
Paso 1: Identificar Clases de Equivalencia
Si la condición de entrada es un:
 Rango, se define una clase de equivalencia válida y dos no válidas
 Valor específico, se define una clase de equivalencia válida y dos no válidas.
 Miembro de conjunto, se define una clase de equivalencia válida y otra no válida.
 Lógica, se define una clase válida y otra no válida
Partición Equivalente
Paso 2: Identificar Clases de Equivalencia
Asignar un número único a cada clase de equivalencia
 Escribir casos de prueba que cubran tantas clases válidas incorporadas como sea posible
hasta que se cubran todas las clases de equivalencia válidas
 Escribir casos de prueba que cubran una sola clase no válida incorporada hasta que se
cubran todas las clases de equivalencia no válidas.
 Pruebas de Caja Negra
 Análisis de Valores Límite
  La técnica de Análisis de Valores Límites selecciona casos de prueba que ejerciten los
valores límite.
 Complementa la prueba de partición equivalente. En lugar de realizar la prueba con
cualquier elemento de la partición equivalente, se escogen los valores en los bordes de
la clase.
 Se derivan tanto casos de prueba a partir de las condiciones de entrada como con las de
salida.
Pruebas de Caja Negra
Ejemplo
https://riunet.upv.es/handle/10251/63579
ANÁLISIS DE VALORES LÍMITE
La técnica se enfoca en la identificación de los casos de prueba asociados con los valores límites
del dominio de la función tanto de entrada como de salida.
Un valor en el límite inferior del rango de entrada min
Un valor por encima del límite inferior min
Un valor valido dentro del rango de entrada val
Un valor por debajo del límite superior max

Un valor en el límite superior del rango de entrada max

Por lo tanto, el análisis de valores límite complementa la técnica de partición de equivalencia de

manera que:
En lugar de seleccionar cualquier caso de prueba de las clases válidas e inválidas, se eligen los
casos de prueba en los extremos.
En lugar de centrase sólo en el dominio de entrada, los casos de prueba se diseñan también
considerando el dominio de salida.
Ventajas de la técnica:
 La técnica reduce el número de casos de pruebas que deben ser creados y ejecutados.
 Esta técnica permite elegir un subconjunto de las pruebas que son eficientes y eficaces
en encontrar no conformidades.
  La experiencia muestra que los casos de prueba que exploran las condiciones límite
producen mejor resultado que aquellos que no lo hacen.
Desventajas de la técnica:
 No prueba todas las entradas posibles.
 No prueba las dependencias entre las combinaciones de entrada.
 No se puede identificar qué porcentaje del sistema ha sido probado.

Ejemplo
https://www.youtube.com/watch?v=mIj2HDcnLBM