Técnicas de diseño de pruebas

1.- Causa y Efecto

El uso de grafos de causa - efecto es una técnica de casos de prueba que proporciona una concisa
representación de las condiciones lógicas y sus correspondientes acciones. La técnica sigue cuatro pasos:
1. Se listan para un módulo las causas (condiciones de entrada) y los efectos (acciones), asignando un
identificador a cada uno de ellos.
2. Se desarrolla un grafo causa - efecto
3. Se convierte el grafo en una tabla de decisión
4. Se convierten las reglas de la tabla de decisión a casos de prueba
Si se ha usado una tabla de decisión como herramienta de diseño, los grafos causa - efecto ya no son
necesarios.
Para la construcción del grafo entonces se parte de los operadores booleanos, partimos de los siguientes
conceptos:

Seguimos entonces los siguientes pasos para la construcción:

1. Dividir la especificación en piezas que sean ‘trabajables’. No intentar crear un simple grafo para toda la
especificación.
2. Identificar Causas y Efectos:
 Una causa es una única condición de entrada.
 Un efecto es una condición de salida o transformación del sistema.
3. Traducir las relaciones semánticas en cada segmento en relaciones booleanas enlazando causas con
efectos. Es decir, construir los grafos.
4. Colocar las restricciones que se aplican a las causas y efectos

5. Crear una Tabla de Decisión resumiendo todas las posibles combinaciones de estados
 Las Causas son las entradas
 Los Efectos son las salidas
 Las Columnas son los casos de prueba
6. Dividir las entradas de la tabla en reglas, una por cada combinación única de estados en el grafo.
 Indicar cuales combinación de estados están asociados con los efectos colocando una X (o un 1) en la
columna que representa esa combinación estado condición.
 Convertir cada columna (regla) de la tabla de decisión en un caso de test

Ejemplo
Requerimientos para calcular primas en seguros de autos:
 Para mujeres de menos de 65 años, la prima es de $500
 Para hombres de menos de 25 años, la prima es de $3000
 Para hombres entre 25 y 64 años, la prima es de $1000
 Para cualquiera de más de 65 años, la prima es de $1500
Primer paso, Identificar Causas y efectos

Segundo paso, elaboramos grafos

Tercer paso, elaboramos la Tabla de decisión

Cuarto paso, elaboramos casos prueba

2.- Clase Equivalencia
La partición de equivalencia es un método de prueba de Caja Negra que divide el campo de entrada de un
programa en clases de datos de los que se pueden derivar casos de prueba. La partición equivalente se dirige
a una definición de casos de prueba que descubran clases de errores, reduciendo así el número total de
casos de prueba que hay que desarrollar.
En otras palabras, este método intenta dividir el dominio de entrada de un programa en un número finito de
clases de equivalencia. De tal modo que se pueda asumir razonablemente que una prueba realizada con un
valor representativo de cada clase es equivalente a una prueba realizada con cualquier otro valor de dicha
clase. Esto quiere decir que si el caso de prueba correspondiente a una clase de equivalencia detecta un
error, el resto de los casos de prueba de dicha clase de equivalencia deben detectar el mismo error. Y
viceversa, si un caso de prueba no ha detectado ningún error, es de esperar que ninguno de los casos de
prueba correspondientes a la misma clase de equivalencia encuentre ningún error.
El diseño de casos de prueba según esta técnica consta de dos pasos:
1. Identificar las clases de equivalencia.
2. Identificar los casos de prueba.
Identificar las clases de equivalencia
Una clase de equivalencia representa un conjunto de estados válidos y no válidos para las condiciones de
entrada de un programa. Las clases de equivalencia se identifican examinando cada condición de entrada
(normalmente una frase en la especificación) y dividiéndola en dos o más grupos. Se definen dos tipos de
clases de equivalencia, las clases de equivalencia válidas, que representan entradas válidas al programa, y
las clases de equivalencia no válidas, que representan valores de entrada erróneos. Estas clases se pueden
representar en una tabla
Condición Externa Clases de equivalencia validas Clases de equivalencia no validas

En función de cuál sea la condición de entrada se pueden seguir las siguientes pautas identificar las clases de
equivalencia correspondientes:
 Si una condición de entrada especifica un rango de valores, identificar una clase de equivalencia válida y
dos clases no válidas. Por ejemplo, si un contador puede ir de 1 a 999, la clase válida sería “1 <=
contador <= 999. Mientras que las clases no válidas serían “contador < 1” y “contador > 999”
 Si una condición de entrada especifica un valor o número de valores, identificar una clase válida y dos
clases no válidas. Por ejemplo, si tenemos que puede haber desde uno hasta seis propietarios en la vida
de un coche. Habrá una clase válida y dos no válidas: “no hay propietarios” y “más de seis propietarios”.
 Si una condición de entrada especifica un conjunto de valores de entrada, identificar una clase de
equivalencia válida y una no válida. Sin embargo, si hay razones para creer que cada uno de los
miembros del conjunto será tratado de distinto modo por el programa, identificar una clase válida por
cada miembro y una clase no válida. Por ejemplo, el tipo de un vehículo puede ser: autobús, camión, taxi,
coche o moto. Habrá una clase válida por cada tipo de vehículo admitido, y la clase no válida estará
formada por otro tipo de vehículo.
 Si una condición de entrada especifica una situación que debe ocurrir, esto es, es lógica, identificar una
clase válida y una no válida. Por ejemplo, el primer carácter del identificador debe ser una letra. La clase
 válida sería “identificador que comienza con letra”, y la clase inválida sería “identificador que no comienza
con letra”.
 En general, si hay alguna razón para creer que los elementos de una clase de equivalencia no se tratan
de igual modo por el programa, dividir la clase de equivalencia entre clases de equivalencia más
pequeñas para cada tipo de elementos.
Identificar los casos de prueba
El objetivo es minimizar el número de casos de prueba, así cada caso de prueba debe considerar tantas
condiciones de entrada como sea posible. No obstante, es necesario realizar con cierto cuidado los casos de
prueba de manera que no se enmascaren faltas. Así, para crear los casos de prueba a partir de las clases de
equivalencia se han de seguir los siguientes pasos:
1. Asignar a cada clase de equivalencia un número único.
2. Hasta que todas las clases de equivalencia hayan sido cubiertas por los casos de prueba, se tratará de
escribir un caso que cubra tantas clases válidas no incorporadas como sea posible.
3. Hasta que todas las clases de equivalencia no válidas hayan sido cubiertas por casos de prueba, escribir
un caso para cubrir una única clase no válida no cubierta.
La razón de cubrir con casos individuales las clases no válidas es que ciertos controles de entrada pueden
enmascarar o invalidar otros controles similares. Por ejemplo, si tenemos dos clases válidas:
“introducir cantidad entre 1 y 99” y “seguir con letra entre A y Z”, el caso 105 1 (dos errores) puede dar como
resultado 105 fuera de rango de cantidad, y no examinar el resto de la entrada no comprobando así la
respuesta del sistema ante una posible entrada no válida.
Propiedades de un buen caso de prueba
Reduce significativamente el número de los otros casos de prueba
Cubre un conjunto extenso de otros casos de prueba posibles
Clase de equivalencia
Conjunto de entradas para las cuales suponemos que el software se comporta igual
Proceso de partición de equivalencia
Identificar las clases de equivalencia
Definir los casos de prueba
Identificación de las clases de equivalencia
Cada condición de entrada separarla en 2 o más grupos
Identificar las clases válidas así como también las clases inválidas
Ejemplos:
 “la numeración es de 1 a 999”
o clase válida 1 <=num <= 999, 2 clases inválidas num < 1 y num > 999
 “el primer carácter debe ser una letra”
o clase válida el primer carácter es una letra, clase inválida el primer carácter no es una letra
o Si se cree que ciertos elementos de una clase de equivalencia no son tratados de forma
idéntica por el programa, dividir la clase de equivalencia en clases de equivalencia Menores

Proceso de definición de los casos de prueba

1. Asignar un número único a cada clase de equivalencia
2. Hasta cubrir todas las clases de equivalencia con casos de prueba, escribir un nuevo caso de prueba que
cubra tantas clases de equivalencias válidas, no cubiertas, como sea posible
3. Escribir un caso de prueba para cubrir una y solo una clase de equivalencia para cada clase de
equivalencia inválida (evita cubrimiento de errores por otro error)
3.- Valores Límites
La experiencia muestra que los casos de prueba que exploran las condiciones límite producen mejor resultado
que aquellos que no lo hacen. Las condiciones límite son aquellas que se hayan en los márgenes de la clase
de equivalencia, tanto de entrada como de salida. Por ello, se ha desarrollado el análisis de valores límite como
técnica de prueba. Esta técnica nos lleva a elegir los casos de prueba que ejerciten los valores límite.
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.
 Las pautas para desarrollar casos de prueba con esta técnica son:
 Si una condición de entrada especifica un rango de valores, se diseñarán casos de prueba para los dos
límites del rango, y otros dos casos para situaciones justo por debajo y por encima de los extremos.
 Si una condición de entrada especifica un número de valores, se diseñan dos casos de prueba para los
valores mínimo y máximo, además de otros dos casos de prueba para valores justo por encima del máximo
y justo por debajo del mínimo.
 Aplicar las reglas anteriores a los datos de salida.
 Si la entrada o salida de un programa es un conjunto ordenado, habrá que prestar atención a los elementos
primero y último del conjunto.
Ejemplos
La entrada son valores entre -1 y 1
Escribir casos de prueba con entrada 1, -1, 1.001, -1.001
Un archivo de entrada puede contener de 1 a 255 registros
Escribir casos de prueba con 1, 255, 0 y 256 registros
Se registran hasta 4 mensajes en la cuenta a pagar (WOM, ENTEL, etc.)
Escribir casos de prueba que generen 0 y 4 mensajes. Escribir un caso de prueba que pueda causar
el registro de 5 mensajes.
4.- Cobertura de Instrucciones y Decisiones
Muchas técnicas de prueba de caja blanca se basan en el concepto de cobertura de ciertas propiedades o
características del programa. Los criterios de cobertura más comúnmente utilizados son los siguientes:
Cobertura de sentencias. Todas sentencia ejecutable en un programa debe ser invocada al menos una vez.
Cobertura de decisiones: Se diseñan casos de prueba que ejerciten las vertientes verdadera y falsa de cada
decisión en un programa. Con este criterio, se asegura la prueba completa de las estructuras de control del
programa siempre y cuando las decisiones sean simples, esto es, no estén formadas por la combinación
lógica de condiciones. Además, por definición, se asegura la cobertura de sentencias.
Cobertura de condiciones. Cada condición en una decisión debe tomar los valores verdadero y falso al
menos una vez, sin ser necesario que cada decisión tome todos los casos posibles a la vez.
Cobertura de condición/decisión. Este criterio combina las dos anteriores, es decir, se deben diseñar casos
de prueba suficientes para que cada decisión y cada condición tomen los valores verdadero y falso; por tanto,
cumple todos los criterios anteriores.
Cobertura de condición/decisión modificada (MC/DC). Mejora el criterio de condición/decisión, requiriendo
además que cada condición afecte independientemente a la evaluación de su decisión.
Cobertura de múltiple condición. Esta cobertura requiere la evaluación de todas las posibles combinaciones
de valores de cada condición en cada decisión. Obviamente esta medida de cobertura es la más completa de
las anteriores, sin embargo, es poco práctica debido al gran número de casos de prueba que es necesario
diseñar para su cumplimiento.
Para la acción Introducirlibro, en un programa cualquiera, se exponen en la siguiente tabla, cuatro casos de
prueba que aseguran el criterio de cobertura de decisiones. Para todos los casos se considera como entrono
un catálogo que contenga los siguientes libros: 1-345-11893-0, 1-810-91328-7, 2-192-78955-5, todos ellos
con stock de 3. Además, estará en oferta el libro 2-192-78955-5, siendo la fecha de validez de la oferta hasta
el 01-03-2019

id Caso de prueba Decisión 1 Decisión 2 Decisión 3

1 ISBN =2-348-81109-1
Unidades = 1 Cierta
Hoy = 10-01-2019
2 ISBN= 1-810-91328-7 Falsa Cierta
Unidades = 6
Hoy = 10-01-2019
3 ISBN = 1-345-11893-0 Falsa Falsa Falsa
Unidades = 2
Hoy = 10-02-2020
4 ISBN=2-192-78955-5 Falsa Falsa Cierta
Unidades = 1
Hoy = 11-06-2019
5.- Lógica proposicional
Una lógica proposicional es un sistema formal cuyos elementos más simples representan proposiciones, y
cuyas constantes lógicas, llamadas conectivas lógicas, representan operaciones sobre proposiciones, capaces
de formar otras proposiciones de mayor complejidad.
La lógica proposicional trata con sistemas lógicos que carecen de cuantificadores, o variables interpretables
como entidades. En lógica proposicional si bien no hay signos para variables de tipo entidad, sí existen signos
para variables proposicionales (es decir, que pueden ser interpretadas como proposiciones con un valor de
verdad definido), de ahí el nombre proposicional. La lógica proposicional incluye además de variables
interpretables como proposiciones simples signos para conectivas lógicas, por lo que dentro de este tipo de
lógica puede analizarse la inferencia lógica de proposiciones a partir de proposiciones, pero sin tener en cuenta
la estructura interna de las proposiciones más simples.
Considérese el siguiente argumento:
1. Mañana es miércoles o mañana es jueves.
2. Mañana no es jueves.
3. Por lo tanto, mañana es miércoles.
Es un argumento válido. Quiere decir que es imposible que las premisas (1) y (2) sean verdaderas y
la conclusión (3) falsa.
Sin embargo, a pesar de que el argumento sea válido, esto no quiere decir que la conclusión sea verdadera.
En otras palabras, si las premisas son falsas, entonces la conclusión también podría serlo. Pero si las premisas
son verdaderas, entonces la conclusión también lo es. La validez del argumento no depende del significado de
las expresiones «mañana es miércoles» ni «mañana es jueves», sino de la estructura misma del argumento.
Estas premisas podrían cambiarse por otras y el argumento permanecería válido. Por ejemplo:
1. Hoy está soleado o está nublado.
2. Hoy no está nublado.
3. Por lo tanto, hoy está soleado.
La validez de los dos argumentos anteriores depende del significado de las expresiones «o» y «no». Si alguna
de estas expresiones se cambia por otra, entonces los argumentos podrían dejar de ser válidos. Por ejemplo,
considérese el siguiente argumento inválido:
1. Ni está soleado ni está nublado.
2. No está nublado.
3. Por lo tanto, está soleado.
Estas expresiones como «o» y «no», de las que depende la validez de los argumentos, se llaman conectivas
lógicas. En cuanto a expresiones como «está nublado» y «mañana es jueves», lo único que importa de ellas es
que tengan un valor de verdad. Es por esto que se las reemplaza por simples letras, cuya intención es simbolizar
una expresión con valor de verdad cualquiera. A estas letras se las llama variables proposicionales, y en general
se toman del alfabeto latino, empezando por la letra p (de «proposición») luego q, r, s, etc. Es así que los dos
primeros argumentos de esta sección se podrían reescribir así:
1. p o q
2. No q
3. Por lo tanto, p
Y el tercer argumento, a pesar de no ser válido, se puede reescribir así:
1. Ni p ni q
 2. No q
3. Por lo tanto, p
A continuación hay una tabla que despliega todas las conectivas lógicas que ocupan a la lógica proposicional,
incluyendo ejemplos de su uso en el lenguaje natural y los símbolos que se utilizan para representarlas
en lenguaje formal

En la lógica proposicional, las conectivas lógicas se tratan como funciones de verdad. Es decir,
como funciones que toman conjuntos de valores de verdad y devuelven valores de verdad. Por ejemplo, la
conectiva lógica «no» es una función que si toma el valor de verdad V, devuelve F, y si toma el valor de verdad
F, devuelve V. Por lo tanto, si se aplica la función «no» a una letra que represente una proposición falsa, el
resultado será algo verdadero. Si es falso que «está lloviendo», entonces será verdadero que «no está
lloviendo».
El significado de las conectivas lógicas no es nada más que su comportamiento como funciones de verdad.
Cada conectiva lógica se distingue de las otras por los valores de verdad que devuelve frente a las distintas
combinaciones de valores de verdad que puede recibir. Esto quiere decir que el significado de cada conectiva
lógica puede ilustrarse mediante una tabla que despliegue los valores de verdad que la función devuelve frente
a todas las combinaciones posibles de valores de verdad que puede recibir.
Bibliografía:
http://www.grise.upm.es/htdocs/sites/extras/12/pdf/PruebasEstaticasSP.pdf
https://testingbaires.com/istqb-capitulo-4-tecnicas-de-diseno-de-pruebas/
http://taller1cdsucn.blogspot.com/2013/08/tecnicas-de-caja-negra.html
https://slideplayer.es/slide/10239366/
Ingeniería de software, Roger S Pressman 5ª edición
Técnicas de evaluación de Software, Natalia Juristo, Ana María Moreno, Sira Vegas
www.wikipedia.org