<<Técnicas de Diseño de Pruebas -

Técnicas de Caja Negra>>

Curso: Pruebas de Software
 13
¿QUE ES UNA TECNICA DE PRUEBA?
 01 ¿QUÉ ES UNA TÉCNICA DE PRUEBA?

¿Por qué las técnicas de diseño de pruebas?

• El proceso de desarrollo de pruebas que se describe en esta sección puede

llevarse a cabo de varias maneras:
• desde muy informal, con poca o ninguna documentación
• hasta muy formal.
• El nivel de formalidad dependerá de:
• contexto de las pruebas, incluyendo la madurez de las pruebas,
• los procesos de desarrollo,
• las limitaciones de tiempo, costo y alcance.
• los requisitos de seguridad o normativos y
• las personas implicadas.

Ing. Alejandro Bartra

3
 01 ¿QUÉ ES UNA TÉCNICA DE PRUEBA?

¿Por qué las técnicas de diseño de pruebas?

• Establecer la trazabilidad a partir de las condiciones de prueba en base a:

• Las especificaciones y requisitos .
• Obtener un análisis de impacto efectivo cuando los requisitos cambian,
como determinar la cobertura de requisitos para una serie de pruebas.
• Durante el Análisis de pruebas debe adoptarse un enfoque de pruebas detallado para
seleccionar las técnicas de diseño de prueba a utilizar en función, entre otras
consideraciones, a los riesgos identificados.
• Durante el Diseño de pruebas se crean y especifican los casos de prueba y los datos de
prueba. Un caso de prueba consta de una serie de valores de entrada, precondiciones
de ejecución, resultados esperados y condiciones de ejecución cuyo desarrollo tiene por
objeto cubrir uno o varios objetivos de prueba o post-condiciones de prueba específicos.

Ing. Alejandro Bartra

4
 01 ¿QUÉ ES UNA TÉCNICA DE PRUEBA?

• Un procedimiento para seleccionar o diseñar las pruebas.

• Basado en un modelo estructural o funcional del software.
• Tienen éxito en la búsqueda de fallos.
• Es una «mejor» práctica.
• Una forma de crear casos de prueba adecuados.
• Una manera de medir objetivamente un esfuerzo de la prueba.

La prueba debe ser rigurosa, profunda y sistemática

Ing. Alejandro Bartra

5
 01 ¿QUÉ ES UNA TÉCNICA DE PRUEBA?

Ventajas de las técnicas de pruebas:

• Diferentes personas: la probabilidad encontrar defectos similares.

• tener una cierta independencia de pensamiento.
• Pruebas efectivas: encontrar más fallos.
• centrar la atención en determinados tipos de fallos.
• Saber que se está probando lo correcto.
• Pruebas eficientes: encontrar fallas con menos esfuerzo.
• evitar la duplicación.
• técnicas sistemáticas son medibles.

Ing. Alejandro Bartra

6
 14
PRUEBAS DE CAJA BLANCA Y CAJA NEGRA
 02 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

Tres tipos de técnica sistemática

• Estática (no ejecución)

• examen de la documentación, código fuente, etc.

• Funcional (Caja Negra)

• funcionalidad basada en el comportamiento de
software.

• Estructural (Caja Blanca)

• basado en la estructura de software.

Ing. Alejandro Bartra

8
 02 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA
Algunas técnicas de
Static
prueba
Dynamic
Reviews Static Analysis

Control Flow. Specification-Based

Inspection
Data Flow
Walkthroughs Functional

Desk-checking Structure-Based Non-functional

etc.
etc.
Control Equivalence
Flow Usability Partitioning

Performance Boundary
Value Analysis
Statement
Decision Tables
Branch/Decision

Branch Condition State Transition

Branch Condition Use Case Testing

Combination
Ing. Alejandro Bartra
9
 02 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

PRUEBAS DE CAJA NEGRA

• No se basan en conocimiento del diseño o del código interno. Las pruebas se basan solo
en los requisitos y su funcionalidad. Solo se conocen las entradas válidas y los
resultados esperados.

• Facilita la separación de funciones entre “tester” y desarrollador.

• Facilita, desde fases iniciales, la planificación de las pruebas.

• Más eficiente en grandes piezas de código.

• Las pruebas se realizan “casi” desde el punto de vista del usuario.

• Ayuda a identificar problemas en las especificaciones y a detectar y evitar errores antes.

• Están limitadas por las posibilidades “ocultas” del código.

• Importancia de cobertura de los requisitos.

• Mayor dificultad en la identificación del origen del problema, por tanto mayor tiempo en
depuración y corrección.

Ing. Alejandro Bartra

10
 02 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

PRUEBAS DE CAJA BLANCA

• Se basan en conocimiento de la lógica interna del código de la aplicación.

• Las pruebas se basan en cobertura de sentencias de código, condiciones, ramas de

código y caminos.

• Las pruebas no se pueden comenzar a diseñar hasta que no está listo el código.

• El código debe ser fácilmente legible.

• Se apoya en herramientas de monitorización para encontrar los puntos de mayor uso de

CPU.

• Ayuda a conseguir buenos y eficientes juegos de datos para las pruebas.

• Probar intensivamente los parámetros de entrada a las funciones.

• Mayor claridad a la hora de reportar los defectos, por tanto mayor rapidez en la corrección.

• Ayuda a eliminar líneas de código “extra”.

• Pruebas Unitarias, Análisis estático y dinámica, Cobertura de sentencias, Cobertura de

ramas, Pruebas de seguridad.

Ing. Alejandro Bartra

11
 02 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

Caja Negra versus caja blanca

Caja Negra. Acceptance

En todos los niveles, pero
mas dominante en los
niveles de pruebas más
altos. System
Caja blanca, utilizada
predominantemente
a niveles más bajos
para complementar Integration
caja negra.

Component

Ing. Alejandro Bartra

12
 15
TECNICAS DE PRUEBAS DE CAJA NEGRA
 03 TECNICAS DE PRUEBAS DE CAJA NEGRA

Diseño de las pruebas de Caja Negra*

• Partición de Equivalencia

• Análisis del Valor Límite

• Tablas de Decisión Causa-efecto de gráficos

• Pruebas de Transición de Estados

• Casos de Uso

*Definidas en norma BS 7925-2

Ing. Alejandro Bartra

14
 03 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

Particiones de Equivalencia

•Clasificación de las condiciones de entrada, de tal forma que cada miembro de la clase
causa el mismo tipo de procesamiento y genera la misma salida.

•Reduce drásticamente el número de casos de prueba requeridos para probar un

sistema de una forma razonable.

•Busca el mayor número de errores con el menor número de casos de pruebas.

•Tomar cada condición.

Ing. Alejandro Bartra

15
 03 TECNICAS DE PRUEBAS DE CAJA NEGRA

Partición de Equivalencia

• División (partición) de las entradas, salidas, etc. en zonas que son iguales
(equivalentes)
• Hipótesis: si un valor funciona, todo funciona.
• Tener pruebas de cada partición es una mejor que todas de una.

No válido válido No válido

0 1 100 101

Ing. Alejandro Bartra

16
 03 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

Análisis de Valores Limite (BVA)

•Técnica de selección de juegos de datos donde los valores se toman entre los valores
extremos.

•Incluye máximo, mínimo, justo en el límite de dentro, justo en el límite de fuera, valores
típicos, valores de error.

•Genera un juego de casos de prueba pequeño.

•No prueba dependencias entre combinaciones de datos de entrada.

•No prueba todas las posibles entradas.

Ing. Alejandro Bartra

17
 03 TECNICAS DE PRUEBAS DE CAJA NEGRA

Análisis del valor límite (BVA)

• Fallas tienden a esconderse cerca de las fronteras.

• Buen lugar para buscar las fallas.
• Los valores de prueba en ambos lados de los límites.

No válido válido No válido

0 1 100 101
Ing. Alejandro Bartra
18
 03 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

Ejemplo: Solicitud de préstamo

2-64 chars.
Nombre del cliente
Número de cuenta 6 digits, 1st
non-zero
Monto del préstamo
Solicitado £500 to
Plazo del préstamo £9000
Cuota mensual 1 to 30 years

Minimum £10
Plazo:
Reembolso:
Tasa de interés:
Total pagado:

Ing. Alejandro Bartra

19
 03 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

Nombre del cliente

Número de caracteres:

1 2 64 65
no valido valido No valido
Caracteres válidos: A-Z
Cualquier
-’ a-z
space otro

Particiones Particiones no Límites Límites no

Condiciones
válidas válidas válidos válidos
< 2 chars 2 chars 1 chars
Nombre del 2 a 64 chars
> 64 chars 65 chars
cliente 64 chars
valid chars invalid chars 0 chars

Ing. Alejandro Bartra

20
 03 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

Número de Cuenta

válido: non-zero
Primer caracter:
No válido: zero

Número de dígitos:
5 6 7
No válido No válido
válido

Particiones Particiones Límites Límites no

Condiciones
válidas no válidas válidos válidos
< 6 digits 5 digits
6 digits 100000
Número de > 6 digits 7 digits
Cuenta 1st digit = 0
1st non-zero 999999 0 digits
non-digit

Ing. Alejandro Bartra

21
 03 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

Monto del préstamo

499 500 9000 9001

No válido válido No válido

Particiones Particiones Límites Límites no

Condiciones
válidas no válidas válidos válidos
< 500
>9000 500 499
Monto del 0
500 - 9000
préstamo
non-numeric
9000 9001
null

Ing. Alejandro Bartra

22
 03 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

Plantilla de condiciones

Límites no
Condiciones Particiones válidas Tag Particiones no válidas Tag Límites válidos Tag Tag
válidos

2 - 64 chars V1 < 2 chars X1 2 chars B1 1 char D1

Nombre de
Cliente > 64 chars X2 65 chars D2
valid chars V2 64 chars B2
invalid char X3 0 chars D3
< 6 digits X4 5 digits D4
6 digits V3 100000 B3
Número de > 6 digits X5 7 digits D5
cuenta 1st digit = 0 X6
st
1 non-zero V4 999999 B4 0 digits D6
non-digit X7
< 500 X8
500 B5 499 D7
>9000 X9
Monto de 0 X10
500 - 9000 V5
préstamo
non-integer X11 9000 B6 9001 D8
null X12

Ing. Alejandro Bartra

 03 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

Diseño de casos de prueba

Caso Tags
Descripción Resultado Esperado
Prueba Covered
1 Name: John Smith Term: 3 years V1, V2,
Acc no: 123456 Repayment: 79.86 V3, V4,
Loan: 2500 Interest rate: 10% V5 .....
Term: 3 years Total paid: 2874.96

2 Name: AB Term: 1 year B1, B3,

Acc no: 100000 Repayment: 44.80 B5, .....
Loan: 500 Interest rate: 7.5%
Term: 1 year Total paid: 537.60

Ing. Alejandro Bartra

24
 03 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

Tablas de Decisión

• Las técnicas de Partición de Equivalencia y Análisis de Valores Límite son

frecuentemente aplicadas a entradas específicas o situaciones puntuales y tienden a
estar más enfocadas a la interface de usuario.

• Las Tablas de Decisión están más enfocadas a la lógica/reglas del negocio y son una
buena técnica para manejar las combinaciones de entrada.

• Son muy útiles para analistas y desarrolladores .

• Proveen una manera sistemática para manejar reglas de negocio complejas.

• Son usadas en el diseño de pruebas sin importar si fueron usadas en las

especificaciones de requerimientos ya que ayudan a explorar los efectos de las
combinaciones de diferentes entradas y otros estados del software que deben
implementar correctamente reglas de negocio.

• Tiene el benéfico efecto de encontrar problemas y ambigüedades en las

especificaciones.

• Es una técnica que trabaja bien en conjunción con las Particiones de Equivalencia. La
combinación de condiciones exploradas pueden ser combinaciones de Particiones de
Equivalencia.

Ing. Alejandro Bartra

25
 03 TECNICAS DE PRUEBAS DE CAJA NEGRA

Tablas de Decisión

Condiciones Regla 1 Regla 2 Regla 3 Regla 4

Condición 1
Condición 2

• Identificar funciones o subsistemas cuyo comportamiento que reaccione acorde a

combinaciones de entradas o eventos.
• Colocar los aspectos a combinar en una tabla y listar todas las combinaciones
posibles.
• Si se tiene, dividir gran número de condiciones en subconjuntos y trabajar con uno
por vez..

Ing. Alejandro Bartra

26
 03 TECNICAS DE PRUEBAS DE CAJA NEGRA

Tablas de Decisión – Ejemplo:

• Aplicación de Préstamos - Especificación:
• Puede ingresarse la cantidad de reembolso mensual o el número de años en
el que se desea pagar.
• Si se ingresan ambos el sistema hará una evaluación si es que entran en
conflicto.

Condiciones Regla 1 Regla 2 Regla 3 Regla 4 *

Importe de la devolución mensual V V F F

Duración del préstamo V F V F

• Se identifica la salida correcta para cada combinación.

Condiciones Regla 1 Regla 2 Regla 3 Regla 4

Importe de la devolución mensual V V F F
Duración del préstamo V F V F
Acción / Resultado
Procesar devolución mensual V V
Procesar duración del préstamo V V

* Número de reglas es «2» elevado al número de condiciones.

Ing. Alejandro Bartra

27
 03 TECNICAS DE PRUEBAS DE CAJA NEGRA

Tablas de Decisión – Ejemplo:

• ¿Qué sucede si no se ingresa ninguna condición?
• Asumamos que esta combinación genera un mensaje de error, por lo que
necesitamos otra acción.

Condiciones Regla 1 Regla 2 Regla 3 Regla 4

Importe de la devolución mensual V V F F
Duración del préstamo V F V F
Acción / Resultado
Procesar devolución mensual V V
Procesar duración del préstamo V V
Mensaje de Error V

• Esto resalta la fortaleza de la técnica en descubrir omisiones o ambigüedades en las

especificaciones.

Ing. Alejandro Bartra

28
 03 TECNICAS DE PRUEBAS DE CAJA NEGRA

Tablas de Decisión – Ejemplo:

• Aplicación de Préstamos – Especificación_v2 :
• Aplicación de préstamo en donde se puede ingresar la cantidad de reembolso
mensual o el número de años en el que se desea pagar.
• Si se ingresan ambos el sistema hará una evaluación si es que entran en
conflicto.
• El sistema no permitirá ingresar ambas condiciones a la vez: importe de
devolución mensual y duración del préstamo

Condiciones Regla 1 Regla 2 Regla 3 Regla 4

Importe de la devolución mensual V V F F
Duración del préstamo V F V F
Acción / Resultado
Procesar devolución mensual V
Procesar duración del préstamo V
Mensaje de Error V V

• Luego deben generarse casos de prueba que ejecuten cada una de las reglas

Ing. Alejandro Bartra

29
 03 TECNICAS DE PRUEBAS DE CAJA NEGRA

Tablas de Decisión – Ejemplo:

• Aplicación de Tarjeta de Crédito: Especificación_v1:
• Si apertura una nueva cuenta de tarjeta de crédito, obtendrá un 15% de
descuento en todas las adquisiciones del día de hoy.
• Si es un cliente existente y mantiene una tarjeta de fidelidad, obtendrá un
10% de descuento.
• Si tiene un cupón, obtendrá el 20% de descuento el día de hoy (el cual no
puede ser usado con el descuento por ser nuevo cliente)
• Los descuentos son acumulables, si fuese aplicable.

Condiciones Regla 1 Regla 2 Regla 3 Regla 4 Regla 5 Regla 6 Regla 7 Regla 8

Nuevo Cliente (15%) V V V V F F F F
Tarjeta de Fidelidad (10%) V V F F V V F F
Cupón (20%) V F V F V F V F
Acción / Resultado
Descuento (%) X X 20 15 30 10 20 0

Ing. Alejandro Bartra

30
 03 PRUEBAS DE CAJA BLANCA Y CAJA NEGRA

Transición de Estados

• Es usada cuando algunos aspectos del sistema pueden ser descritos en una
«máquina de estados finita».

• Existe un número de estados determinados y las transiciones de un estado a otro son

determinados por las reglas de la máquina.

• Cualquier sistema donde se tengan diferentes salidas para la misma entrada,

dependiendo de lo que haya ocurrido antes, es un sistema de estados finitos; y es
frecuentemente mostrado como un diagrama de estados.

• Un modelo de transición de estados tiene cuatro partes básicas:

• Los estados que el software puede tener en un momento determinado.
• Las transiciones de un estado a otro.
• Los eventos que causan la transición.
• Las acciones que resultan de una transición.
• En cualquier estado, un evento puede causar solo una acción, pero el mismo evento,
desde diferentes estados, puede causar una acción diferente y un diferente estado final.

Ing. Alejandro Bartra

31
 03 TECNICAS DE PRUEBAS DE CAJA NEGRA

Transición de Estados

• En el gráfico se observan siete (7) estados y cuatro (4) posibles eventos.

• Un primer caso de prueba puede ser una situación normal donde el PIN es ingresado
correctamente la primera vez.
• Un segundo caso debería ingresar el PIN incorrecto tres veces con el fin que el
sistema retenga la tarjeta.
• Las condiciones de prueba pueden derivarse del gráfico de los estados y las
transiciones. En el caso de las transiciones pueden agruparse una o más de estas.
• Una de la ventajas es que el modelo puede ser tan detallado o abstracto como se
necesite que sea: detallado para lo crítico/importante y simple para lo menos
importante.

Ing. Alejandro Bartra

32
 03 TECNICAS DE PRUEBAS DE CAJA NEGRA

Transición de Estados: Pruebas para transiciones no válidas

• La generación de casos de prueba, con el diagrama de estados, es conveniente; pero
no se puede visualizar adecuadamente las transiciones no válidas.
• Para poder visualizar la combinación total de estados y transiciones (válidas y no
válidas) es útil una tabla de estados.
• La tabla de estados lista todos los estados y todos los eventos que causan una
transición. Cada celda representa un par: estado-evento.
• El contenido de cada celda indica a cual estado el sistema deberá pasar cuando un
correspondiente evento ocurra mientras se encuentre asociado a un determinado
estado.
• Se deberán incluir los posibles eventos erróneos, que son los eventos que no se
esperan que ocurran en ciertos estados; estas son las condiciones negativas.

Insertar Tarjeta PIN Correcto PIN Erróneo

S1. Inicio S2 ─ ─
S2. Esperar por PIN ─ S6 S3
S3. 1er Intento ─ S6 S4
S4. 2do Intento ─ S6 S5
S5. 3er Intento ─ ─ S7
S6. Acceso a Cuenta ─ ? ?
S1 (para nueva
S7. Retener Tarjeta ─ ─
tarteja)

Ing. Alejandro Bartra

33
 03 TECNICAS DE PRUEBAS DE CAJA NEGRA

Pruebas de Casos de Uso

• Es una técnica que ayuda a identificar casos de prueba que ejecuten el sistema,
transacción por transacción, de inicio a fin.
• Por su naturaleza, los casos de uso sirven como el fundamento para desarrollar casos
de prueba, mayormente en los niveles de sistema y de aceptación.
• Debido a que los casos de uso describen el flujo de procesos del sistema basado en
su uso más probable, hace que los casos de prueba derivados de estos sean
particularmente buenos para hallar defectos que ocurrirían en el mundo real.
• Cada caso de uso, tiene un flujo principal y uno o más flujos alternativos, que cubren
casos especiales o condiciones excepcionales.
• Para las pruebas deberíamos contar con una prueba para el flujo principal y
satisfactorio y una prueba para cada flujo alternativo.
Paso Descripción
1 A: Insertar tarjeta
Flujo Principal
Satisfactorio 2 S: Valida tarjeta y solicita PIN
3 A: Ingresa PIN
A: Actor 4 S: Valida PIN
S: Sistema
5 S: Permite acceso a cuenta
Tarjeta no válida
2a
S: Muestra un mensaje y rechaza la tarjeta
PIN erróneo
Extensiones 4a
S: Muestra un mensaje y solicita reintento (2 veces)
PIN erróneo por tercera vez
4b
S: Retiene tarjeta y sale del sistema

Ing. Alejandro Bartra

34