Testing con Máquinas de Estado (1 de 3)

Las máquinas de estado (también conocidas como FSM del inglés finite state machines) son modelos del comportamiento de un sistema o de una parte de un sistema. Se representan con grafos dirigidos donde los nodos corresponden a los estados y las aristas a las transiciones entre dichos estados.

En la imagen podemos ver un ejemplo súper simple y gráfico. Tenemos modelado el comportamiento de una lámpara, donde esta puede tener dos estados: encendida o apagada. Las flechas muestran las transiciones entre estos estados las cuales están asociadas a una acción (la de presionar el botón del interruptor).

Estos modelos son sumamente útiles en el área de desarrollo de software para modelar de manera abstracta el comportamiento de un sistema, pudiendo entenderlo mejor y discutir con otros sobre lo que se espera y lo que no.

Por todo esto es que lo veo como una herramienta súper útil para un tester, aunque lamentablemente bastante subutilizada en la industria. Eso me llevó a escribir una serie de posts para explicar la técnica de derivación de pruebas a partir de máquinas de estado. Preparé tres artículos:

El Modelo

Sigamos con el ejemplo de la lámpara planteado más arriba. Esta situación tan cotidiana la podemos representar con la siguiente máquina de estado:

Veamos más en detalle cómo está compuesto este modelo:

  • Estado: Los estados son condiciones en las que está un sistema mientras espera por uno o más eventos (encendida, apagada, etc.). El mismo evento puede ocasionar comportamientos distintos en los distintos estados (esa es la forma de distinguir los estados). Por ejemplo, el mismo evento “presionar interruptor” genera distintas acciones según en el estado en el que se encuentra el sistema. 
  • Evento: Es el estímulo “externo” que recibe el sistema que causa un cambio en su estado. Por ejemplo, el evento “presionar interruptor” hace que la luz cambie de estado. Una vez que se da un evento el sistema puede cambiar de estado, permanecer en el estado actual y/o ejecutar una acción. 
  • Acción: Una acción es una operación que se inicia a partir de un evento. Por ejemplo, luego de “presionar interruptor” se ejecuta la acción de “apaga lámpara”.
  • Transición: Una transición está representada por una flecha y a su vez indica que se da un cambio, un pasaje de un estado a otro estado. En cada una de estas flechas podremos ver conceptos de guardas (condiciones), eventos y acciones. 
  • Guarda: Es una condición que debe darse para que el evento ocasione que se vaya por una determinada transición. En el ejemplo, podríamos agregar una transición más (otra flecha) que vaya de “apagada” a “apagada” (un lazo sobre el mismo estado) agregando la guarda que diga “no hay electricidad”. 

Veamos ahora cómo generar casos de prueba para las máquinas de estado según los criterios de cobertura.

Cobertura de Máquinas de Estado

Las máquinas de estado pueden utilizarse para diseñar casos de prueba que la recorran atendiendo a algún criterio de cobertura. Algunos de estos criterios de cobertura son:

  • Cobertura de estados: Este criterio se satisface cuando los casos de prueba recorren todos los estados.
  • Cobertura de transiciones: En este caso cuando se recorren todas las transiciones.
  • Cobertura de pares de transiciones: Para cada estado se cubren las combinaciones de transiciones de entrada y salida.

Este tipo de técnicas es de las más usadas en el mundo del Model-based Testing (MBT), para lo que te recomiendo que investigues sobre el trabajo de Harry Robinson.

Siguiendo con el ejemplo de la lámpara, veamos qué pasa con estos casos de prueba:

  • Caso de prueba 1: Lámpara apagada, sin electricidad, presiono el interruptor. 
  • Caso de prueba 2: Lámpara apagada, con electricidad, presiono el interruptor. 
  • Caso de prueba 3: Lámpara encendida, presiono el interruptor. 

Es interesante observar que solo con el caso de prueba 2 ya tengo cobertura de estados. Si quisiera cubrir todas las transiciones, entonces necesito los casos de prueba 1, 2 y 3. Para poder cubrir los pares de transiciones debería realizar más flujos aún sobre el sistema. Esto muestra cómo un criterio subsume a otro.

Leave a Reply

Your email address will not be published. Required fields are marked *