X
BLOG

Uso de la virtualización de servicios para superar los obstáculos de los datos de prueba

Uso de la virtualización de servicios para superar los obstáculos de los datos de prueba Tiempo de leer: 5 minutos

 


Los datos son un problema de costos

Uno de los principales desafíos a los que se enfrentan los desarrolladores y evaluadores de software a diario proviene de la incapacidad de obtener datos realistas. Muchas veces, como desarrollador, está interactuando con un servicio en sentido descendente y debe utilizar los datos disponibles en ese entorno porque el proceso para obtener datos utilizables reales para su escenario consume mucho tiempo. A menudo, no puede encontrar los datos que necesita y deben tomarse de producción, lo que presenta una nueva serie de desafíos.

Para complicar las cosas, los datos personales de producción no se pueden utilizar porque aumentan el riesgo de robo, pérdida o exposición de una organización. Tomemos la brecha reciente en Yahoo, donde se violaron 500 millones de cuentas de correo electrónico, o los ~ 68 mil millones de usuarios de LinkedIn cuyos datos se vieron comprometidos recientemente. Estas infracciones se produjeron en el nivel de producción, donde la seguridad es alta. Los datos de producción utilizados en áreas de desarrollo no son infrecuentes y la seguridad tiende a ser menor. Operar de esta manera presenta un riesgo significativo para la reputación de la marca de una organización. Por lo tanto, los datos confidenciales deben limpiarse o enmascararse, lo que es un proceso que requiere mucho tiempo y requiere experiencia en datos.


Uso de la virtualización de servicios para superar los costos de datos

Pase lo que pase, los datos son un problema de costos porque lo ralentizan. Al utilizar la virtualización de servicios, no solo puede tomar el control del comportamiento y la funcionalidad de una aplicación dependiente con el fin de estabilizar sus entornos de prueba, sino que puede controlar completamente las fuentes de datos de esas dependencias y proporcionar los datos que necesite ese día para su esfuerzo. En este punto, las reglas cambian porque ahora no solo tienes el control de los datos, sino también la lógica. Puede crear servicios que se comporten de la manera que desee, en lugar de cumplir estrictamente con sus patrones de comportamiento normales.

En un blog anterior, hablé de la virtualización de defectos, que tiene los mismos principios básicos. Pero ahí estábamos hablando de lógica de servicio. Este blog dará el siguiente paso y hablará sobre el control de datos. Al comenzar, centrémonos en el desafío actual de los datos al que se enfrentan los evaluadores y desarrolladores en el día a día.

Un día típico de datos en la vida de un desarrollador

Al comienzo del proceso de desarrollo de una aplicación, los datos requeridos para las pruebas suelen ser simples porque aún no se ha realizado la funcionalidad completa del servicio. A medida que el desarrollo continúa agregando funcionalidad, la madurez de las pruebas aumenta, al igual que la complejidad de los datos.

Por ejemplo, usemos el ejemplo de mi anterior entrada del blog - digamos que soy una aerolínea, desarrollando funcionalidad en mi página de boletos. Necesito verificar que los usuarios puedan obtener boletos para sus vuelos y, dependiendo de qué tan lejos estén los vuelos en el futuro, el usuario recibirá una de varias respuestas, que cambiarán a medida que se acerque el tiempo. Al comienzo del proceso de desarrollo, simplemente podría generar un montón de datos complejos con vuelos de 3 meses en el futuro, lo que me permitiría hacer todas las pruebas que necesito por el momento. Pero, por supuesto, el problema es que encendí la mecha de una bomba de tiempo. En tres meses, estos hermosos datos caducarán y es probable que me haya olvidado de ellos. De repente, todas mis pruebas comenzarán a fallar, exactamente en el momento equivocado porque el lanzamiento se acercará y simplemente no tendré tiempo para volver a generar los datos ... ¿Te suena familiar?

Forjar un camino sostenible

Al introducir la virtualización de servicios al principio del proceso de desarrollo, puede sentar las bases para brindar soluciones a estos desafíos de datos. Los datos de un servicio virtual se pueden derivar de numerosas ubicaciones, pero al principio, los servicios virtuales simples comienzan con datos fijos. Usted crea estos "activos fijos" o simulacros para abordar las etapas de prueba del escenario hipotético y mantener las cosas muy simples. La idea aquí es: "Solo necesito un servicio que responda con esta carga útil en particular".

A medida que los servicios virtuales maduran, es necesario separar los datos del servicio para que, si desea agregar lógica a la simulación, no tenga que abrir el servicio virtual para manipular los datos. De hecho, los usuarios maduros crean un servicio virtual de tal manera que la fuente de datos maneja la mayor parte de la lógica. Luego, pueden entregar la fuente de datos a un evaluador o al equipo de administración de datos de prueba para insertar cualquier dato que este servicio pueda necesitar en el futuro. Agregar nueva funcionalidad al servicio es tan simple como agregar una fila a la fuente de datos. Esto permite compartir el esfuerzo de virtualización y un servicio virtual puede acomodar a varios equipos. Los servicios virtuales se convierten en organismos vivos que crecen y cambian según sea necesario.

¿De dónde vienen estos datos?

Una vez que el desarrollo ha creado el servicio simple inicial, es hora de que el equipo de pruebas se haga cargo. Los equipos de prueba tendrán requisitos de datos más complejos. ¿De dónde vienen estos datos? Normalmente, estos datos se obtienen a partir de la grabación y la reproducción. Este suele ser el primer paso al crear un servicio virtual. Usted registra las transacciones entre una aplicación y los sistemas backend dependientes y usa esta grabación para crear su servicio virtual. Esto le permite crear una fuente de datos de referencia muy útil que se puede ampliar siempre que surja la necesidad. En el ejemplo de mi aerolínea, esto nos permitiría obtener números de vuelo y destinos realistas. Los datos tendrían toda la complejidad necesaria, incluidos vuelos multisegmento e internacionales. La correlación de la fuente de datos maneja todas las relaciones complejas de solicitud / respuesta, y dado que los cambios posteriores a los datos "reales" pueden simplemente volver a registrarse y fusionarse en el servicio virtual existente, obtener nuevos datos se vuelve trivial.

Los datos que registramos no provienen de producción, y esto nos protege contra una filtración de datos en los entornos inferiores. El desafío con estos datos es que, dado que no provienen de producción, no están tan completos ni actualizados. Aquí es donde la generación y manipulación de datos se convierte en una función poderosa de la virtualización de servicios.

Los datos inexistentes se pueden complementar con datos generados simples para lograr exactamente lo que necesitamos. En mi ejemplo de aerolínea, las fechas de vuelo en las respuestas siempre pueden ser la fecha de hoy compensada por 3 meses. Al utilizar la generación de datos, esta tarea se vuelve trivial.

Podemos continuar masajeando y manipulando los datos proporcionando datos dinámicos para gestionar cualquier relación de solicitud / respuesta "no definida". Estos son los tipos de relaciones que nunca podrían existir en un conjunto de datos estáticos. En el ejemplo de la aerolínea, digamos que cuando se realiza una solicitud al componente descendente, proporciona la ubicación actual del usuario y esta se utilizará en la respuesta como la salida. Dado que nuestros casos de prueba cambiarían constantemente, un servicio real tendría que mantener todas las ubicaciones actuales para que se puedan suministrar en la respuesta. Al utilizar un servicio virtual, no necesita mantener todas las ubicaciones, simplemente puede devolver dinámicamente la ubicación actual del usuario como la ciudad de salida.

Por último, el uso de datos negativos puede proporcionarse de forma estática o insertarse en la fuente de datos para facilitar las pruebas negativas o anormales. En el ejemplo de mi aerolínea, por ejemplo, esto sería insertar un vuelo cancelado o retrasado al azar para validar que se notifica al usuario antes de que se vaya al aeropuerto.


En el siguiente video, describo algunos de estos desafíos típicos que enfrentan los desarrolladores cuando trabajan con datos y le muestro cómo superarlos en lo que creo que son algunas formas geniales con la virtualización de servicios.

 

Escrito por

Chris Colosimo

Como Gerente de Producto en Parasoft, Chris elabora estrategias para el desarrollo de productos de las soluciones de pruebas funcionales de Parasoft. Su experiencia en la aceleración de SDLC a través de la automatización lo ha llevado a implementaciones empresariales importantes, como Capital One y CareFirst.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft