¡Descubre GoogleTest, con certificación TÜV y la tecnología Agentic AI para pruebas de C/C++!
Obtenga los detalles »
Saltar a la sección
Blog de Parasoft
Crear una representación virtual estable para lograr un comportamiento con estado de sus cargas de trabajo de desarrollo puede ser complicado. Así es como Parasoft Virtualize puede ayudarlo a simular y probar sus servicios virtuales.
Saltar a la sección
En la virtualización de servicios, un aspecto crucial para crear servicios virtuales realistas es garantizar que el servicio tenga un comportamiento con estado para que pueda conservar su estado entre las diferentes pruebas. Pero, ¿cuál es el límite? ¿Cuándo la simulación se vuelve excesiva? Analicemos las pruebas de transición de estado y cómo saber cuándo son necesarias.
Para acelerar las pruebas funcionales, es esencial tener acceso sin restricciones a un entorno de prueba confiable y realista. Un entorno de prueba completo incluye la aplicación bajo prueba (AUT) y todos sus componentes dependientes, como API, servicios de terceros, bases de datos, aplicaciones y otros puntos finales.
La virtualización de servicios permite a los equipos hacer lo siguiente, lo que en última instancia les permite realizar pruebas antes, más rápido y de forma más completa.
Una parte fundamental de la creación de dependencias virtualizadas realistas es tener un comportamiento con estado. En otras palabras, una dependencia virtualizada puede conservar su estado de ejecución de prueba a 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 el guardado de artículos en el carrito no cambiará el estado del carrito. La prueba de la secuencia 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 compras virtual tiene un comportamiento con estado, donde su estado (vacío o con uno o más elementos) se conserva 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.
Mediante pruebas con estado, el servicio virtualizado ahora puede cambiar de estado de vacío a "lleno con artículo añadido" y devolver la información correspondiente. Si se añade un artículo al carrito y el AUT consulta el carrito, se devuelven los datos correspondientes. Es posible realizar una prueba más realista mediante pruebas con estado, y al consultar el carrito ahora se devuelve el artículo añadido, como se muestra a continuación.
En resumen, para tener servicios virtuales confiables y reutilizables, es fundamental que puedan imitar el servicio real lo suficiente como para proporcionar un resultado significativo a la aplicación que se está probando, y esto puede requerir pruebas con estado.
Además del estado del propio servicio virtual, es posible que también deba simular cambios de estado en función de diferentes entradas potenciales, y esto se denomina prueba de transición de estado.
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 en exactamente uno de un número finito de estados en un momento dado. La FSM puede cambiar de un estado a otro en respuesta a entradas externas; este cambio se denomina transición. Una FSM se define por una lista de sus estados, su estado inicial y las condiciones para cada transición.
Las máquinas de estado son una forma útil de describir objetos y, a menudo, se usan explícitamente como modelo de programación. En otros casos de prueba, como nuestro carrito de compras, podría haber una máquina de estado implícita para describir su comportamiento. Considere la siguiente máquina de estado para el ejemplo anterior del carrito de compras.
El estado inicial del carrito es vacío. A medida que se añaden artículos, el estado cambia de "Vacío" a "Artículo en el carrito". Las transiciones se inician en respuesta a eventos. En este caso, al añadir o eliminar un artículo del carrito.
Las transiciones a menudo tienen condiciones antes de que se tomen, por ejemplo, la transición de regreso al estado Vacío solo ocurre cuando la cantidad de elementos vuelve a ser cero. Las transiciones a menudo realizan acciones, como incrementar el número de artículos en el carrito, en este ejemplo. Aunque es poco probable que el carrito 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, el estado inicial es cerrar sesión. 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 de prueba, la cuenta bloqueada puede considerarse un estado final, ya que no hay forma de pasar de él.
Como se muestra en los dos ejemplos de transición anteriores, los diagramas de estado son representaciones gráficas de máquinas de estado finito. Modelan el comportamiento de un sistema o proceso que puede existir en diferentes estados y las transiciones entre esos estados en función de ciertos eventos o condiciones.
En un diagrama de estado, los estados se representan como cuadros redondeados y las transiciones entre estados son flechas. Cada estado representa una condición particular o modo del sistema. Las transiciones indican cómo el sistema puede pasar de un estado a otro y generalmente se etiquetan con el evento que provoca la transición.
Los eventos en las máquinas de estado pueden ser entradas externas, acciones internas o el paso del tiempo. Cuando ocurre un evento, el sistema sufre una transición y pasa a un nuevo estado.
Las tablas de transición de estado son representaciones tabulares que se utilizan para describir el comportamiento de una máquina de estado de forma sistemática. La tabla define los estados posibles, los eventos de entrada y las transiciones de estado resultantes.
En una tabla de transición de estado, las filas representan estados y las columnas representan un evento o condición de entrada. Las celdas de la tabla especifican el estado resultante cuando ocurre un evento particular en un estado específico. Esto permite una representación concisa y estructurada de las transiciones de estado.
| Estado / Evento | PIN ingresado (comprobar PIN, PIN correcto) | PIN ingresado (PIN, PIN incorrecto, incremento de reintentos, reintentos>=MAX) | PIN ingresado (verificar PIN, PIN incorrecto, incrementar reintentos, reintentos | Cerrar sesión |
|---|---|---|---|---|
| De Desconexión | Conectado | Cuenta bloqueada | De Desconexión | |
| Conectado | De Desconexión | |||
| Cuenta bloqueada |
Las ventajas de utilizar pruebas de transición de estado incluyen las siguientes.
Las pruebas de transición de estado presentan algunas desventajas. La principal es el esfuerzo necesario para representar una API compleja. Si la traducción del comportamiento de la API genera una máquina de estados compleja, será difícil de comprender, usar y mantener. Además, las pruebas de transición de estado son sensibles a los cambios en la API, lo que requiere un mantenimiento constante para estar al día con estas actualizaciones.
La prueba de transición de estado tiene más sentido, como era de esperar, cuando la API tiene una naturaleza con estado, como mantener una sesión o contexto en varias solicitudes. Este tipo de prueba ayuda a verificar que la API administra y mantiene correctamente el estado a lo largo de la interacción, lo que garantiza un comportamiento uniforme en diferentes solicitudes y transiciones.
Las API pueden documentar su comportamiento en términos de estados y eventos, en cuyo caso la verificación puede tomar la misma forma. En otros casos, la API puede involucrar un proceso comercial complejo que tiene múltiples etapas en el flujo de trabajo. Las pruebas de transición de estado se pueden utilizar para probar mejor estos escenarios complejos.
Entonces, ¿cómo ayuda esto con las pruebas y los servicios virtuales? Bueno, es posible usar Parasoft Virtualize para simular un comportamiento con estado, de modo que los servicios devuelvan respuestas apropiadas en cada ejecución de prueba, representando valores realistas esperados por la aplicación bajo prueba.
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 el motor asociado a 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 las solicitudes API recibidas. Estas actualizaciones de datos en la fuente de datos de prueba se basan en eventos de entrada, como los descritos anteriormente en los diagramas de transición de estado: llega un evento de entrada, se produce una transición de estado y se ejecuta una acción.
Para respaldar todo esto, la herramienta de gestión de datos de prueba en Parasoft Virtualize está configurada para realizar una actualización basada en una fuente de datos y un evento entrante.
Las actualizaciones del origen de datos 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: ¿cuándo es demasiada simulación, demasiada?
Aprenda cómo un marco de gestión de datos de prueba estructurados respalda las pruebas continuas.
El uso de la virtualización pura es útil en las pruebas, ya que elimina la complejidad de gestionar un servicio real y aísla la aplicación bajo prueba. Además, la eliminación de los servicios en vivo permite ejecutar las pruebas en paralelo, en varios escritorios simultáneamente, sin afectar a los sistemas de producción ni requerir una copia dedicada del servicio. Sin embargo, un servidor virtual puro solo devuelve una confirmación como "sí, se llamó a esta API". En muchos casos, esto es suficiente, hasta que, por supuesto, deja de serlo. A medida que surgen casos de prueba más complejos, necesitamos que nuestros servidores virtualizados sean más inteligentes.
Usando el ejemplo del carrito de compras anterior, es mucho más útil para tu servicio de compras virtual no solo reconocer que se han añadido artículos, sino simular la adición de artículos. De esta forma, una consulta para determinar la cantidad de artículos en el carrito se ejecutará correctamente con un valor correcto. También podríamos simular un estado de "carrito lleno", como se describe en la representación de la máquina de estados anterior. El comportamiento con estado es necesario para que nuestras pruebas obtengan resultados más significativos y aumenten la cobertura de los casos de prueba.
Pero llega un punto en el que simular la lógica empresarial se vuelve demasiado complejo. La intención de la virtualización es disminuir el trabajo y aumentar la productividad, por lo que hay rendimientos decrecientes en la simulación de la complejidad.
Es difícil determinar el límite, pero si la complejidad va mucho más allá de nuestro ejemplo de carrito de compras o inicio de sesión, entonces resulta difícil justificar el esfuerzo. ¿Cómo podemos asegurarnos de que estamos simulando el comportamiento correcto? ¡No queremos que nuestra aplicación esté diseñada para funcionar con un servicio simulado, pero no funcione correctamente con el real! El uso de servicios en vivo sigue siendo necesario para la validación. Afortunadamente, el módulo Environment Manager de Parasoft CTP facilita el cambio.
El comportamiento con estado es fundamental para crear servicios virtualizados realistas, necesarios para aislar las aplicaciones bajo prueba. Conservar el estado de los datos de prueba entre pruebas es esencial para obtener pruebas más realistas y útiles. Parasoft Virtualize ofrece una solución integral de gestión de datos de prueba que da vida a los servicios virtualizados con respuestas con estado a las entradas de las llamadas a la API.
La simulación debe usarse con cautela, ya que simular una lógica comercial compleja tiene rendimientos decrecientes y el riesgo de alejarse demasiado de la realidad. Un uso inteligente de la simulación genera grandes beneficios de forma aislada, lo que a su vez desacopla las dependencias de los servidores activos. Sin embargo, dado que los servidores en vivo aún desempeñan un papel en la validación final, se requieren herramientas de virtualización de servicios como Parasoft Virtualize para admitir la combinación y combinación de estos entornos sin problemas.
