Calidad de software

Técnicas de Diseño de prueba

Ing: Nestor Chamorro

Universidad de la costa CUC

Noviembre – 2022
 Técnicas de Diseño de Pruebas

Proceso de Desarrollo de pruebas:

¿Cómo obtengo los casos de prueba?

Estos se adquieren a partir de los requisitos, la idea es que estos

respondan a los requisitos con el objetivo de comprobar que lo que se
ha desarrollado, cumple con lo que se necesitaba, deberíamos tener
un proceso controlado para que se den casos de prueba, no debemos
pretende que los casos de pruebas sean los que decidan, si no que
exista una manera ordenada de definir, ¿Cuál es mi objetivo y que nivel
de detalle quiero llegar?. Los casos de prueba pueden tener cierto caso
de formalidad o informalidad y va a depender un poco en el tipo de
proyecto con el que estamos trabajando y la madurez del proceso que
estamos haciendo.

Trazabilidad

Las pruebas deben ser trazables ya que este trae consigo

consecuencias de los cambios en los requisitos sobre las pruebas a
realizar, pueden ser identificadas de forma directa, esto nos ayuda a
determinar la cobertura de requisitos.

Permite establecer la calidad de los casos de prueba en base a los

resultados requeridos.

Objeto de Pruebas:

Es un Elemento para revisar puede ser Un documento o una pieza de

software en el proceso de desarrollo de software.

Condición de prueba:

Es un elemento o evento de un componente o sistema que debería ser

verificado por uno o más casos de pruebas.
Criterio de prueba:

Son los objetos de prueba que debe cumplir con el objeto de superar
la prueba.

Calendario de ejecución de prueba:

Es un esquema para la ejecución de procedimientos de prueba. Los

procedimientos de prueba están incluidos en el calendario de
ejecución de prueba en sus contextos y en el orden en el cual deben
ser ejecutados.

¿Qué es una especificación de diseño de prueba?

Basados en la IEEE829, es un documento que especifica las

condiciones de prueba (Elementos de cobertura) para el elemento de
prueba, el enfoque de prueba de forma detallada e identifica los casos
de prueba de alto nivel asociados (objetivos, entradas acciones de
prueba, resultados esperados y precondiciones de ejecución). Para un
elemento de prueba.

Descripción de un caso de prueba según el estándar IEEE 829

Precondiciones:

Es una situación previa a la ejecución de una prueba o características

de un objeto de prueba antes de llevar a la práctica (Ejecución) un caso
de prueba.

Valores de entrada:

Es la descripción de los datos de entrada de un objeto de prueba.

Resultados esperados: Los datos de salida que se espera que produzca

un objeto de prueba, en el cual también se encuentran
postcondiciones, lo cual son las características de un objeto de prueba
tras la ejecución de una prueba, descripción de su situación tras la
ejecución.
Dependencias: Es el orden en que se debe ejecutar una estación de
prueba, el informe de errores debe hacer referencia al caso de prueba
del que se produjo.

Requisitos:

Características del objeto de prueba que el caso prueba debe evaluar.

Combinación de casos de prueba

Los casos de prueba se pueden combinar en juegos de prueba y

escenarios de pruebas, si tenemos una especificación de
procedimientos de pruebas, este define la secuencia de acciones para
la ejecución de un caso de prueba individual o un juego de pruebas,
por ejemplo: un guion cinematográfico, para la prueba describiendo los
pasos, tratamiento y actividades necesarias para la ejecución de forma
autónoma con el uso de herramientas apropiadas. Los juegos de
prueba pueden ser codificados y ejecutados de forma automática con
el uso de herramientas apropiadas.

Un plan de pruebas es algo dinámico este establece la secuencia de las

pruebas planificadas, quien debe realizarlas y cuando. Se deben
considerar, el calendario de ejecución de prueba define el orden de la
ejecución de los procedimientos de prueba.

En resumen, los casos de prueba y los juegos de pruebas son

obtenidos a partir de los requisitos o características de los objetos de
prueba.
 Categorías de las técnicas de diseño de prueba

Caja
Negra

Caja
Blanca
Caja Negra:

Es cuando tenemos un objeto de prueba sin conocerlo.

En esta se puede llevar a cabo partición de equivalencias, análisis de

valores limite, pruebas de transición de estado, tablas de decisión y
pruebas de caso de uso.

El probador va a ver la caja negra como el objeto de prueba como una

caja negra, la estructura interna del objeto de prueba es irrelevante o
desconocida, los casos de prueba se obtienen a partir del análisis de la
especificación (Funcional y no Funcional) de un componente o sistema,
prueba del comportamiento entrada y salida, la técnica de caja negra
también se denomina prueba funcional o prueba orientada a la
especificación.
Caja Blanca:

Es cuando estamos haciendo verificaciones o pruebas a un objeto de

pruebas conociendo su estructura y su detalle es completo, es decir la
jerarquía de los componentes, flujo de control, flujo de Datos etc. Los
casos de prueba son seleccionados en base a la estructura interna del
programa / código.

A lo largo de las pruebas es posible que se interfiera con la ejecución

de otro tipo de prueba, esta técnica también es conocida como prueba
basada en la estructura o prueba basada en el flujo de control.

Se pueden hacer cobertura de sentencias, decisión y condición.

Si lo vemos de forma general, tenemos metodos que se basan en las

especificaciones, en esta el objeto de prueba responde al modelo
funcional del software, la cobertura y la especificación se puede medir
(por ejemplo: El porcentaje de la especificación cubierta por casos de
prueba)

Cuando nos basamos en la estructura, esta es la que nos permite

generar o armar el diseño (código, sentencias, menús, llamadas, etc.),
el porcentaje de cobertura se mide utilizando como fuente para la
creación de casos de prueba adicionales.

En los metodos basados en la experiencia, es muy importante para

enseñar los casos, el conocimiento y la experiencia son utilizados para
definir casos de prueba, este nos ayuda encontrar un poco por donde
tendríamos debilidades y posibles errores, en resumen, los casos de
prueba pueden ser diseñados utilizando diferentes métodos.

Si la funcionalidad es especificada es el objeto de las pruebas, los

métodos utilizados se denominan métodos basados en la
especificación o métodos de Caja Negra.
Si la estructura interna de un objeto es investigada, los metodos
utilizados se denominan metodos basados en la estructura o métodos
de caja blanca.

En general basadas en la experiencia utilizan el conocimiento y la

habilidad del personal involucrado en el diseño de casos de prueba.

Técnicas basadas en la especificación o de caja negra

Abarca un grupo de técnicas que se utilizan sin conocer el código, sin

esperar que el proveedor tenga idea de cómo funciona el código a nivel
interno, entonces decimos que es una prueba donde vamos a lograr
determinar la conexión, de una forma mucho más eficiente y ordenada.

Las principales técnicas de caja negra son:

- Partición de equivalencia (Seguimiento de equivalencia) o clase

de equivalencia.
- Análisis de valores límite.
- Tablas de decisión y gráficos causa y efecto.
- Pruebas de transición de estado.
- Pruebas de caso de uso.

La lista anterior da cuenta de los metodos más importantes y

conocidos.

Otros metodos de caja negra son:

- Pruebas estáticas.
- Pruebas duales.
- Pruebas de humo.
De forma general las pruebas funcionales están dirigidas a verificar la
corrección y la completitud de una función y en cuanto a la ejecución
de casos de prueba deberían ser ejecutados con una baja redundancia,
pero sin embargo con carácter integral/completo.

Participación de equivalencia o clase de equivalencia

Es lo que la mayoría de los probadores hacen de forma intuitiva:

Dividen los posibles valores en clases, mediante lo cual observan.

Encontramos los valores de entrada de un programa el cual hace uso

habitual del método CE y también podemos encontrar valores de Salida
de un programa el cual hace uso poco habitual del metodo CE.

El rango de valores definido se agrupan en clases de equivalencia para

las cuales se aplican las siguientes reglas:

- Todos los valores para los cuales se espera que el programa

tenga un comportamiento común se agrupan en una clase de
equivalencia (CE).
- Las clases de equivalencia no pueden superponerse y no pueden
presentar ningún salto (Discontinuidad)
- Las clases de equivalencia pueden consistir en un rango de
valores (por ejemplo, o<x<10) o en un valor aislado (por ejemplo:
x = verdadero)

Participación de equivalencia – Válida y no Válida

Las clases de equivalencia de cada variable (Elemento) pueden ser

divididas de forma adicional.

CE válida: Todos los valores dentro del rango de definición se combinan

en una clase de equivalencia, si son tratadas de la misma forma por el
objeto de prueba.
CE no válida: Se distinguen dos casos para valores fuera del rango de
definición:

- Valores del formato correcto, pero con valor fuera del rango, se
pueden combinar en una o más clases de equivalencia.
- Valores con el formato correcto, generalmente, forma parte de
una CE separada.
- Las pruebas son ejecutadas utilizando un único representante de
cada CE.
- Para cualquier otro valor de CE se espera el mismo
comportamiento que el del valor seleccionado.

Partición de equivalencia.

Las clases de equivalencia se escogen para entradas válidas y no

válidas.

Si el valor X se define como 0 < x < 100, entonces, inicialmente, se

pueden identificar tres clases de equivalencia:

- X<0 (Valores de entrada no válidos)

Se puede decir que lo menor que cero.
- 0<X<100 (Valores de entrada válidos)
- X>100 (Valores de entrada no válidos)

Se pueden definir CE adicionales, conteniendo, pero no limitadas a:

- Entradas no numéricas.
- Números muy grandes o pequeños.
- Formatos numéricos no admitidos.

<0 0 - 100 0 - 100

 Este ejemplo tan sencillo entre 0 y 100 ya me esta me define de que
tratan las clases equivalencias.

Participación de equivalencia: Variables de entrada.

Todas las variables de entrada del objeto de prueba son

identificadas, los campos de una interfaz gráfica de usuario,
parámetros de una función (Por ejemplo: componente de prueba).

Se define un rango para cada valor de entrada, este rango define la

suma de todas las clases de equivalencia válidas (CEV) aparte.

La equivalencia válida para este parámetro puede ser más de una

porque el comportamiento que se espera en el objeto de prueba
para diferentes valores validos puede ser distinto, puede que se
haga algo diferente cuando es 0, eso no implica que una clase de
equivalencia distinta para 0, aunque este en el rango valido.

Las clases No validas son las que no pertenecen al rango total del
valor de entrada, ay valores que se pueden tratar de forma diferente
(conocidos o sospechosos) son asignados a una clase de
equivalencia aparte.

Participación de equivalencia Ejemplo:

Un programa espera un valor porcentaje de acuerdo con los siguientes

requisitos:

- Solo se admiten valores enteros.

- 0 pertenece al rango y es su límite inferior.
- 100 pertenece al rango y es su límite superior.
- Son válidos todos los números del 0 al 100, son no válidos todos
los números negativos, los números mayores que 100, todos los
números decimales y todos los valores no numéricos.
 Una clase de equivalencia: 0 < X < 100
1era clase de equivalencia no válida: X<0
2da clase de equivalencia no válida: X > 100
3era clase de equivalencia no válida: X = No entero
4ta clase de equivalencia no válida: X = No numérico (n.n)

Partición de equivalencia – ejemplo 1.

El porcentaje será presentado en un diagrama de barra. Se aplicarán

los siguientes requisitos adicionales (ambos valores incluidos).

Valores entre 0 y 15 Barra color gris

Valores entre 16 y 50 Barra color verde
Valores entre 51 y 85 Barra color amarillo
Valores entre 86 y 100 Barra color rojo

<0 0-15 16-50 51-85 86-100 >100

Ahora hay cuatro clases de equivalencias válidas en lugar de una:

1era clase de equivalencia válida: 0 ≤ X ≤ 15

2da clase de equivalencia válida: 16 ≤ X ≤ 50
3ra clase de equivalencia válida: 51 ≤ X ≤ 85
4ta clase de equivalencia válida: 86 ≤ X ≤ 100
En el último paso, se determina un representante de cada clase de
equivalencia, así como el resultado esperado para cada uno de ellos.

Variable Clase de equivalencia Representantes

Valor porcentaje EC1: 0 ≤ X ≤ 15 +10
(Válido) EC2: 16 ≤ X ≤ 50 +20
EC3: 51 ≤ X ≤ 85 +80
EC4: 86 ≤ X ≤ 100 +90
Valor porcentaje EC5: X < 0 -10
(No Válido) EC6: X > 100 +200
EC7: X no entero 1,5
EC8: X non numérico Fred

Partición en clase de equivalencia – ejemplo 2.

- Análisis de la especificación.
- Parte del código de un programa trata el precio final de un
artículo en base a su propia venta al público, un descuento en %
y el precio del porte, ($6.000, $9.000 o $12.000 )

suposición:

- El precio de venta al público de un artículo está dado por un

número con dos decimales.
- El descuento es el valor porcentual sin decimales entre 0% y
100% -- el precio del porte puede ser 6, 9 o 12
 Variable Clase de equivalencia Estado Representante
Precio de EC11: X >=0 Válido 1000,00
venta al EC12: X < 0 No válido -1000,00
público EC13: X valor no num No válido Fuera formato
EC21: 0 % <= X <= 100% Válido 10%
EC22: X < 0% No válido -10%
Descuento
EC23: X > 100% No válido 200%
EC24: X Valor no num No válido Fuera formato
EC31: X = 6 Válido 6
EC32: X = 9 Válido 9
Precio del
EC33: X = 12 Válido 12
porte
EC34: X ≠ {6,9,12} No válido 4
EC35: X Valor no num No válido Fuera formato

Ninguna de estas equivalencias es complicada, se deben estudiar una

por una para poder aclarar.

Las clases de equivalencia válidas aportan las siguientes

combinaciones o casos de prueba: Test 01, Test 02 y Test 03.

Como son tres variables, podemos tener tres casos de prueba, para
que cada representante trabaje con ella y tengamos combinaciones
validas.

Por ejemplo, no podemos probarlas por separados, pero podemos

hacer combinaciones.

Podríamos decir un precio de venta valido con un descuento valido mas

un precio del porte valido y así sucesivamente con esto logramos tener
combinaciones de equivalencia valida.

Ejemplo
 Clase de T01 T02 T03
Variable Estado Representante
equivalencia
EC11: X >=0 Válido 1000,00 X X X
Precio de No
EC12: X < 0 -1000,00
venta al válido
público EC13: X valor No
Fuera formato
no num válido
EC21: 0 % <= X X X
Válido 10%
X <= 100%
No
EC22: X < 0% -10%
válido
Descuento
EC23: X > No
200%
100% válido
EC24: X Valor No
Fuera formato
no num válido
EC31: X = 6 Válido 6 X
EC32: X = 9 Válido 9 X
EC33: X = 12 Válido 12 X
Precio del
EC34: X ≠ No
porte 4
{6,9,12} válido
EC35: X Valor No
Fuera formato
no num válido

AQUÍ PODRIAMOS COMBINARLOS:

La franja amarilla es una combinación, la verde es otra y la azul es

otra, solo de las que tenemos validas, las cuales se muestran con la X.

CE no validas:

Casos de prueba.

El siguiente caso de prueba ha sido generado utilizando CE no validas,

cada una en combinación con CE Validas de otros elementos:
 Clase de T0 T0 T0 T0 T0 T0 T1
Estad Representant
Variable equivalenci 4 5 6 7 8 9 0
o e
a
EC11: X V V V X X
Válido 1000,00
>=0
Precio de No X
EC12: X < 0 -1000,00
venta al válido
público EC13: X X
No Fuera
valor no
válido formato
num
EC21: 0 % X X X X
<= X <= Válido 10%
100%
EC22: X < No X
-10%
Descuent 0% válido
o EC23: X > No X
200%
100% válido
EC24: X X
No Fuera
Valor no
válido formato
num
EC31: X = 6 Válido 6 X X X X X
EC32: X = 9 Válido 9
EC33: X =
Válido 12
12
Precio del
EC34: X ≠ No X
porte 4
{6,9,12} válido
EC35: X X
No Fuera
Valor no
válido formato
num

EN ESTE CASO TOMAMOS.

Una No valida como lo es el -1.000 del precio de venta al público,

seguimos del descuento que, si es válido y el cual representa un 10%,
seguido de otro elemento valido que hace parte del precio del porte
para un valor de 6.000.

El caso como tal me esta testeando una equivalencia No Valida porque

ya utilizo una No valida la cual es el -1000, de este modo puedes hacer
combinaciones, para las NO validas.
Actividad.

Realiza un ensayo de 3 hojas como mínimo y 5 como máximo, con

todas las normas apa, partiendo de todos los temas que hemos visto
este corte.