paint-brush
Un análisis de las técnicas de diseño de pruebas combinatoriaspor@shad0wpuppet
23,460 lecturas
23,460 lecturas

Un análisis de las técnicas de diseño de pruebas combinatorias

por Konstantin Sakhchinskiy7m2024/01/24
Read on Terminal Reader
Read this story w/o Javascript

Demasiado Largo; Para Leer

Pruebas de tablas de decisiones: utilice tablas para documentar los requisitos y describir la funcionalidad de la aplicación. Conveniente para la representación de lógica empresarial y la creación de casos de prueba. Pruebas de transición de estado: visualice los estados y las transiciones del sistema mediante diagramas o tablas. Útil para documentar los requisitos y la estructura del sistema. Matrices ortogonales: utilice matrices para explorar todas las combinaciones de valores para pares de variables de manera eficiente. Algoritmo AllPairs: céntrese en probar todas las combinaciones de valores para cada par de variables, lo que reduce la necesidad de probar todas las combinaciones posibles.
featured image - Un análisis de las técnicas de diseño de pruebas combinatorias
Konstantin Sakhchinskiy HackerNoon profile picture
0-item

Omitiré discutir aquí técnicas de diseño de pruebas bien conocidas y ampliamente utilizadas, como las clases de equivalencia, las pruebas de valor en la frontera y las pruebas por pares; discutiré otras técnicas menos comunes. También puede leer mi artículo sobre problemas con técnicas de diseño de pruebas combinatorias .


Prueba de tabla de decisiones

Las tablas de decisiones son una excelente herramienta para documentar requisitos y describir la funcionalidad de una aplicación. Estas tablas son muy convenientes para describir la lógica empresarial de la aplicación y, además, pueden servir como una base sólida para crear casos de prueba. Si la aplicación probada carece de la documentación adecuada, es una buena razón para utilizar tablas de decisión. Presentar los requisitos de forma compacta y sencilla facilita la creación de casos de prueba.


Acercarse:

Las tablas de decisión describen la lógica de la aplicación en función de las entidades (propiedades/condiciones) del estado del sistema. Cada tabla de decisiones solo debe describir un estado del sistema.


regla 1

regla 2

regla norte

Entidades





Propiedad 1









Propiedad m





Comportamiento





Acción 1









Acción P





La entidad (propiedad) del 1 al M representa varias propiedades del sistema; se presentan en la tabla como datos de entrada que se pueden ingresar al sistema. Las acciones del 1 al P son acciones que pueden ocurrir con la combinación especificada de entidades. Dependiendo de la combinación de todos los datos de entrada de las entidades, las acciones toman los valores necesarios. Cada regla define un conjunto único de datos de entrada para todas las propiedades que conducen a la ejecución de acciones específicas.


Después de componer la tabla de decisiones, generalmente es posible simplificarla, por ejemplo, eliminando algunos o todos los escenarios imposibles. Luego, la tabla se puede transformar en casos de prueba.


Pruebas de transición de estado

Las pruebas de transición de estado, al igual que las pruebas de tablas de decisión, son una herramienta valiosa para documentar los requisitos y describir la estructura y el diseño de un sistema. A diferencia de las pruebas de tablas de decisión, que describen un estado específico del sistema, las pruebas de transición de estado describen cómo pueden cambiar estos estados del sistema. Los diagramas definen todos los eventos que ocurren durante el funcionamiento de la aplicación y cómo la aplicación responde a estos eventos.


Acercarse:

Hay dos tipos de representaciones visuales de esta técnica:

  1. Diagramas de transición de estado
  2. Tablas de transición de estado

Diagramas de transición de estado

Como ejemplo, consideremos la reserva de billetes de avión. Funciona aproximadamente de la siguiente manera: inicialmente, los clientes proporcionan a la aerolínea información para la reserva: lugar de salida, destino, fecha y hora de salida. Un empleado de la aerolínea actúa como interfaz entre el cliente y el sistema de reserva de boletos, utilizando la información proporcionada por el cliente para crear una reserva. Después de eso, la reserva del cliente pasa al estado "Realizada". Además, después de crear la reserva, el sistema inicia un cronómetro. Cuando el cronómetro expira y el boleto reservado no ha sido pagado, el sistema cancela la reserva de ese boleto.


El círculo representa el estado del sistema de reserva de billetes de avión, el estado "Hecho". La flecha indica una transición al estado "Hecho". La descripción debajo de la flecha ("get_info") es un evento que se origina fuera del sistema. El comando en la descripción debajo de la flecha (después de "/") significa que el sistema realizó alguna acción en respuesta al evento; en este caso, inició un temporizador. El círculo negro indica el punto de inicio/entrada del diagrama.


Si el cronómetro no expira y hemos pagado el billete reservado, el sistema entra en estado "Pagado". Esto se representa mediante la flecha denominada "payMoney" y la transición del estado "Hecho" al estado "Pagado".


  • Estado (representado como un círculo en el diagrama) : este es el estado del sistema donde espera uno o más eventos. El estado recuerda los datos de entrada recibidos hasta el momento e indica cómo reaccionará el sistema ante los eventos recibidos. Los eventos pueden desencadenar acciones y/o conducir a un cambio de estado.
  • Transición (representada en el diagrama como una flecha) : representa una transición de un estado a otro, que ocurre debido a un evento.
  • Evento (representado como un rectángulo encima de la flecha) : un evento es algo que hace que la aplicación cambie su estado. Los eventos pueden provenir de fuera de la aplicación, como a través de la interfaz de usuario de la aplicación. Al mismo tiempo, la propia aplicación puede generar eventos, por ejemplo, un evento como "el temporizador expiró". Cuando ocurre un evento, la aplicación puede permanecer en el mismo estado, cambiar de estado o realizar una acción. Los eventos pueden tener parámetros; por ejemplo, el evento "pay_money" puede tener parámetros como "Efectivo", "Cheque", "Tarjeta de débito" o "Tarjeta de crédito".
  • Acción (representada después de "/" en la etiqueta encima de la transición) : esta es una acción iniciada por un cambio de estado. Podrían ser acciones como "imprimir ticket", "mostrar en pantalla", etc. Normalmente, las acciones crean resultados que sirven como datos de salida del sistema. Las acciones ocurren durante las transiciones; Los propios estados son pasivos.
  • El punto de entrada se muestra en el diagrama como un punto negro.
  • El punto de salida se muestra en el diagrama como un símbolo de "diana".

Tablas de transición de estado

Las tablas de transición de estado son tablas que constan de cuatro columnas: Estado actual, Evento, Acción y Estado siguiente.

La ventaja de las tablas de transición de estado es que definen todos los escenarios posibles de transición de estado, no solo los correctos. Por lo tanto, las tablas de transición de estado a menudo conducen al descubrimiento de combinaciones de transición de estado indefinidas y no documentadas, que es mejor identificar antes de escribir el código.


  • Los diagramas de transición de estado se pueden utilizar fácilmente para crear casos de prueba. Es necesario crear un conjunto de casos de prueba que deberían cubrir todas las transiciones al menos una vez.
  • A partir de las tablas de transición de estado, también es relativamente sencillo generar casos de prueba. Es necesario pasar por todas las combinaciones válidas (si el tiempo lo permite o los riesgos no lo prohíben, también es posible pasar por todas las combinaciones no válidas).

Matrices ortogonales

¿Cuántas combinaciones existen para el par de valores "1" y "2"? {1,1}, {1,2}, {2,1} y {2,2}. Una matriz ortogonal es una matriz bidimensional con una propiedad especial: en dos columnas cualesquiera de la matriz, todas las combinaciones de valores en esas columnas están presentes. Es decir, si toma dos columnas cualesquiera de la matriz ortogonal, donde los valores solo pueden ser "1" o "2", encontrará las siguientes filas para esas columnas: {1,1}, {1,2}, { 2,1} y {2,2}.

Como ejemplo, considere un sistema con tres parámetros de entrada, cada uno de los cuales es binario (es decir, toma el valor "1" o "2").

filas

variable 1

variable 2

variable 3

1

1

1

1

2

2

1

1

3

1

2

1

4

1

1

2

5

2

2

1

6

1

2

2

7

2

1

2

8

2

2

2

La matriz ortogonal se representa como - L_4(2^3), donde L_4 indica que la matriz ortogonal tiene cuatro filas y (2^3) indica que la matriz tiene tres columnas, con valores que pueden ser "1" o "2 ".

filas

variable 1

variable 2

variable 3

1

1

1

1

2

1

2

2

3

2

1

2

4

2

2

1

L_4, donde 4 es el número de filas

2^3, donde 2 es el valor máximo (== 2, 3,…, N) y 3 es el número de columnas


Matriz ortogonal: es una matriz bidimensional con la siguiente propiedad: elija dos columnas cualesquiera de la matriz y encontrará todas las combinaciones de valores en esas columnas.

Usando matrices ortogonales:

  1. Identificar variables (número de datos de entrada). Es necesario seleccionar los datos de entrada, cualquier combinación de valores que pueda existir lógicamente.
  2. Determine el número de valores que puede tomar cada variable. Para cuando se determina el número de valores, ya deberían haberse aplicado otras técnicas de diseño de pruebas para reducir el número de valores (por ejemplo, valores límite, clases de equivalencia y cualquier otro).
  3. Determine una matriz ortogonal donde habrá una columna para cada variable (la columna de la matriz ortogonal tiene tantas opciones de valor como la variable).
  4. Proyecte la tarea de prueba en la matriz ortogonal.
  5. Escribe casos de prueba.

Algoritmo de todos los pares

La esencia del algoritmo AllPairs es que no es necesario probar todas las combinaciones de valores para todas las variables. En cambio, se centra en probar todas las combinaciones de valores para cada par de variables.



Como profesional de control de calidad, es importante comprender estos matices. Si bien es teórico en algunos casos, comprender la complejidad de las técnicas de diseño de pruebas combinatorias permite a los profesionales de control de calidad probar de manera efectiva la complicada lógica empresarial de las aplicaciones y ofrecer software de alta calidad a sus usuarios.