Agregar vida a la virtualización de servicios: pruebas de transición de estado y estado

En la virtualización de servicios, una parte fundamental de la creación de servicios virtuales realistas es garantizar que el servicio tenga un comportamiento con estado para que pueda conservar su estado de una prueba a otra. Pero, ¿cuál es el límite? ¿Cuándo la simulación se convierte en demasiada simulación? Profundicemos en las pruebas de transición de estado y cómo saber cuándo las necesita.

Para acelerar las pruebas funcionales, es esencial tener acceso sin restricciones a un entorno de prueba realista y confiable. Un entorno de prueba completo incluye la aplicación bajo prueba (AUT) y todos sus componentes dependientes (por ejemplo, API, servicios de terceros, bases de datos, aplicaciones y otros puntos finales).

La virtualización de servicios permite a los equipos (1) obtener acceso a ese entorno de prueba completo que necesitan, incluidos todos los componentes críticos del sistema dependiente, y (2) alterar el comportamiento de esos componentes dependientes de formas que serían imposibles con un entorno de prueba por etapas. De esta forma, los equipos pueden realizar pruebas antes, más rápido y de forma más completa.

Comportamiento con estado

Una parte fundamental de la creación de dependencias virtualizadas realistas es tener un comportamiento con estado. En otras palabras, una dependencia virtualizada que puede conservar su estado desde la ejecución de prueba hasta la ejecución de prueba. Considere un ejemplo de simulación de un componente de carrito de compras virtualizado. Una API simple permite buscar, agregar, recuperar y eliminar artículos del carrito. Con el comportamiento sin estado, simular la búsqueda y guardar artículos en el carrito no cambiará el estado del carrito. La prueba de los procesos de recuperación y eliminación de datos del carrito fallará porque el carrito permanecerá en su estado inicial (vacío), como se ilustra a continuación:

Sin embargo, si el carrito de la compra virtual tiene un comportamiento con estado, donde su estado (vacío o con uno o más elementos en él) se retiene de una prueba a otra, y también cambia según las entradas de la aplicación bajo prueba, puede comenzar a probar el proceso de manera significativa.

Con las pruebas de estado, el servicio virtualizado ahora puede cambiar el estado de vacío a "lleno con elemento agregado" y devolver la información adecuada. Si se agrega un artículo al carrito y AUT consulta al carrito, se devuelven los datos correspondientes. Es posible realizar una prueba más realista utilizando pruebas de estado, y al consultar el carrito ahora se devuelve el artículo agregado, como se muestra a continuación:

En resumen, para tener servicios virtuales confiables y reutilizables, es fundamental que puedan imitar el real servicio suficientemente para proporcionar resultados significativos a la aplicación bajo prueba, y esto puede requerir pruebas con estado.

Además del estado del servicio virtual en sí, es posible que también deba simular cambios en estado basado en diferentes entradas potenciales, y esto se llama prueba de transición estatal.

¿Qué son las pruebas de transición estatal?

Las transiciones de estado son el componente de acción de las máquinas de estados finitos, que se definen como:

“… Una máquina abstracta que puede estar exactamente en uno de un número finito de estados en un momento dado. El FSM puede cambiar de un estado a otro en respuesta a algunas entradas externas; el cambio de un estado a otro se llama transición. Un FSM se define mediante una lista de sus estados, su estado inicial y las condiciones para cada transición ". - Wikipedia

Las máquinas de estado son una forma útil de describir objetos y, a menudo, se utilizan explícitamente como modelo de programación. En otros casos, como nuestro carrito de compras, puede haber una máquina de estado implícita para describir su comportamiento. Considere la siguiente máquina de estado para el ejemplo de carrito de compras anterior:

El estado inicial del carrito es vacío y, a medida que se agregan artículos al carrito, el estado cambia de "Vacío" a "Artículo en el carrito". Las transiciones se inician en respuesta a eventos (en este caso, agregar o quitar un artículo del carrito).

Las transiciones a menudo tienen condiciones antes de que se tomen, por ejemplo, la transición al estado Vacío solo ocurre cuando el número de elementos vuelve a ser cero. Transiciones a menudo realizar acciones, como incrementar el recuento de artículos en el carrito, en este ejemplo. Aunque es poco probable que el carro esté programado como una máquina de estados, hay uno implícito que es útil para definir su comportamiento.

Considere otro ejemplo simple de un componente de inicio de sesión de usuario que bloquea a un usuario después de una cierta cantidad de reintentos:

En el componente de inicio de sesión, se cierra la sesión del estado inicial. Un usuario solo puede iniciar sesión cuando se ingresa un PIN correcto. Después de un número definido de intentos de inicio de sesión (MAX_RETRIES), la cuenta se bloquea. En este caso, la cuenta bloqueada se puede considerar un estado final, ya que ahora hay una forma de hacer la transición.

Simulando estado con Parasoft Virtualize

Entonces, ¿cómo ayuda esto con las pruebas y los servicios virtuales? Bueno, es posible usar Virtualización de Parasoft para simular el comportamiento con estado de modo que los servicios devuelvan las respuestas adecuadas de una ejecución de prueba a otra, representando valores realistas esperados por AUT.

Los servicios virtualizados reaccionan a la entrada de las pruebas y conservan los valores según sea necesario, lo que amplía la utilidad de los datos de prueba capturados y simulados, que permanecen estáticos a menos que se mejoren con un comportamiento con estado. En Parasoft Virtualize, un servicio se virtualiza como "CRUD" (Crear, Leer, Actualizar, Eliminar) para indicar que su fuente de datos de prueba es persistente y se puede manipular según sea necesario durante la prueba. Vea la captura de pantalla a continuación:

Parasoft Virtualize admite el comportamiento con estado en la fuente de datos de prueba (o motor) asociado con cada servicio virtual, que no solo almacena datos de prueba, sino que también proporciona la herramienta CRUD para manipular datos en función de la reacción a las solicitudes de API recibidas. Estas actualizaciones de los datos en la fuente de la fecha de prueba se basan en eventos de entrada (como los que se discutieron anteriormente en los diagramas de transición de estado: llega el evento de entrada, ocurre la transición de estado, se lleva a cabo la acción).

Para admitir todo esto, la herramienta de administración de datos de prueba en Parasoft Virtualize está configurada para realizar una actualización basada en una fuente de datos y un evento de llegada:

Las actualizaciones de la fuente de la fecha de prueba pueden ser elementos de datos individuales u objetos completos. La herramienta también le permite crear y eliminar registros según las reglas comerciales requeridas. De hecho, es lo suficientemente potente como para simular un comportamiento complejo, lo que plantea la pregunta de cuándo es demasiada simulación, demasiada.

Los pros y los contras de la virtualización con estado

El uso de virtualización pura es muy útil en las pruebas, ya que elimina la complejidad de tratar con un servicio real y aísla la aplicación bajo prueba. Además, la eliminación de los servicios en vivo significa que las pruebas se pueden ejecutar en paralelo, en varios escritorios al mismo tiempo, sin afectar los sistemas de producción o la necesidad de una copia dedicada del servicio. Pero un servidor virtual puro solo devuelve un reconocimiento como en "sí, se llamó a esta API". En muchos casos, esto es suficiente, hasta que, por supuesto, no lo es. A medida que surgen casos de uso más complejos, necesitamos que nuestros servidores virtualizados se "mejoren".

Usando el ejemplo del carrito de compras anterior, es mucho más útil para su servicio de compras virtuales no solo reconocer que se han agregado artículos al carrito, sino que en realidad simula agregar artículos al carrito. De esta manera, una consulta para determinar la cantidad de artículos en el carrito tendrá éxito con un valor correcto. También podríamos simular un estado de "carro lleno" como se describe en la representación de la máquina de estado anterior. El comportamiento con estado es necesario para dar a nuestras pruebas resultados más significativos y una mayor cobertura de casos de uso.

Pero llega un punto en el que la simulación de la lógica empresarial se vuelve demasiado compleja. La intención de la virtualización es disminuir el trabajo y aumentar la productividad, por lo que hay rendimientos decrecientes al simular la complejidad. El límite es difícil de decir, pero si la complejidad va mucho más allá de nuestro carrito de compras o ejemplo de inicio de sesión, entonces es difícil justificar el esfuerzo. ¿Cómo está seguro de que está simulando el comportamiento correcto? ¡No desea una situación en la que su aplicación esté construida para funcionar con un servicio simulado pero incorrectamente con el real! El uso de servicios en vivo todavía es necesario en la validación (afortunadamente, Parasoft's Gerente de medio ambiente módulo facilita el cambio).

Resumen

El comportamiento con estado es una parte fundamental de la creación de servicios virtualizados realistas, necesarios para ayudar a aislar las aplicaciones bajo prueba. La capacidad de retener el estado de los datos de prueba de una prueba a otra es necesaria para obtener pruebas más realistas y útiles. Virtualización de Parasoft proporciona una solución integral de gestión de datos de prueba que da vida a los servicios virtualizados con respuestas con estado y basadas en el estado a las entradas de las llamadas a la API.

La simulación debe usarse con precaución, ya que la simulación de lógica empresarial compleja tiene rendimientos decrecientes, con el riesgo de alejarse demasiado de lo "real". Un uso inteligente de la simulación ofrece grandes beneficios de forma aislada, lo que a su vez desacopla las dependencias de los servidores en vivo; sin embargo, dado que los servidores en vivo todavía juegan un papel en la validación final, se requieren herramientas de virtualización de servicios como Parasoft Virtualize para admitir sin problemas la combinación y combinación de estos entornos.