Cuando haya mantenido su Oracle BRM (Gestión de facturación e ingresos) durante algún tiempo, empieza a darse cuenta de que la cantidad de entidades configuradas no para de crecer. Para entonces, es muy probable que también haya desarrollado algunas personalizaciones y se haya integrado con soluciones adicionales. La evolución de su entorno da lugar a un complejo cúmulo de objetos entrelazados. Llega un momento en el que usted, o su cliente, deciden cambiar algo. Al principio, la nueva función puede parecer fácil de desarrollar. La verdad, sin embargo, es que muy probablemente chocará con una característica existente, o requerirá también la actualización de la configuración existente. Lo que parecía un simple cambio, luego afecta a todo el sistema. A veces es difícil evitar este tipo de incidencias, pero estar preparado para ellas puede ahorrarle muchos problemas. Los escenarios de pruebas funcionales y la versatilidad de las pruebas pueden cambiar las reglas del juego.
Índice
Flujo de desarrollo continuo
En Tridens hemos establecido un flujo de desarrollo continuo. Todas nuestras configuraciones BRM, personalizaciones y otros componentes integrados están debidamente versionados y rastreados en un sistema de control de versiones distribuido (Git). Esta práctica permite a nuestros desarrolladores consultar las versiones necesarias de los componentes en cualquier momento y comenzar su trabajo. Todo va bien hasta este punto, pero ¿cómo abordamos la posibilidad de que las nuevas funciones rompan la compilación actual?
Tenemos un flujo de despliegue y pruebas establecido, que realiza un seguimiento de los repositorios remotos de nuestras fuentes. En consecuencia, cada vez que un desarrollador realiza un commit y empuja algunos cambios al control de versiones, se inicia el proceso de pruebas. El flujo de despliegue construye imágenes Docker para todos los componentes relevantes con sus últimas versiones en un entorno local (o remoto), y se ejecutan pruebas automatizadas para garantizar que la construcción es estable. Sólo cuando las pruebas tienen éxito, podemos lanzar las nuevas versiones a producción. Este proceso nos ayuda a garantizar que las nuevas funciones funcionen a la perfección con las ya existentes. Las pruebas ejecutadas forman parte del Oracle BRM TestToolkit, que hemos desarrollado. El BRM TestToolkit tiene pasos y escenarios predefinidos con código de cola de fondo. Los pasos son muy descriptivos y fáciles de usar, lo que permite a nuestros desarrolladores o a cualquier otro usuario escribir nuevos escenarios de pruebas rápidamente. Encontrará un ejemplo de escenarios de prueba en la imagen inferior.
BRM TestToolkit para pruebas automatizadas
Lo que comenzó como simples escenarios de prueba para la creación de cuentas y la compra de productos, representa hoy en día, el grueso de nuestras pruebas BRM TestToolkit. Para aclarar, ahora tenemos varios casos de prueba diferentes y escenarios de casos marginales para garantizar la máxima cobertura de las funciones implementadas. Las pruebas automatizadas permiten a nuestros desarrolladores centrarse en la tarea que tienen entre manos y no dedicar grandes cantidades de tiempo a las pruebas manuales. Por supuesto, a veces, nos encontramos desarrollando una nueva característica que aún no está cubierta por los escenarios de prueba. En esos casos, las definiciones de los pasos de las pruebas y su código de fondo se implementan como parte de esa característica, para que se utilicen también en el futuro.
El TestToolkit puede comunicarse con distintos componentes, lo que permite realizar ajustes rápidos también para otros sistemas. También utilizamos versiones rediseñadas de nuestro BRM TestToolkit para nuestros otros componentes. Una de las últimas características que añadimos fue la modularidad, con la que los desarrolladores pueden etiquetar diferentes escenarios de prueba como partes de un grupo. Cada grupo tiene entonces sus guiones y su lógica separada, lo que permite, si se desea, ejecutar sólo un número específico de pruebas a la vez y en paralelo. Además, la modularidad nos permite separar las pruebas de valoración de prepago de las de pospago o las pruebas de compras complementarias de las de compras varias. Puede ver el flujo de pruebas en la siguiente imagen.
Cobertura del escenario de prueba
El BRM TestToolkit se comunica con nuestra API, que hemos integrado con Oracle BRM para simplificar las operaciones más complejas. El TestToolkit también puede interactuar con el BRM RestBridge, nuestra solución envoltorio de BRM, que facilita la comunicación con BRM al permitir el uso del formato JSON o XML a través de una API REST. Las definiciones de los pasos de prueba admiten, entre otras muchas, las siguientes operaciones:
- Creación y gestión de cuentas
- Compra de operaciones y otras operaciones
- Recuperación y comprobación del saldo
- Generación de tráfico - Eventos de uso
- Llamadas API
- Abandono del CDR
- herramientas de tráfico en tiempo real (protocolo diameter)
- Comprobaciones de calificación
- El BRM TestToolkit compara diferentes eventos de uso y compras con los valores esperados
- cada plan o producto diferente puede tener su propio conjunto de archivos de calificación, lo que garantiza la versatilidad en configuraciones de productos complejas
Al componer los pasos de prueba de fácil uso, cada desarrollador puede escribir los escenarios para la característica en desarrollo. En muchos casos, nuestros desarrolladores optan por preparar los escenarios de prueba por adelantado, antes de desarrollar la característica. Preparar los escenarios con antelación sigue el patrón de desarrollo impulsado por el comportamiento (BDD). BDD significa esencialmente que los escenarios dictan el flujo de desarrollo y deben existir de antemano. Estos escenarios describen cómo debe comportarse el sistema, y los desarrolladores deben desarrollar las nuevas características de forma que se ajusten a estos escenarios. Podemos ejecutar cada escenario de prueba por separado, dando como resultado un informe en un formato especificado. A continuación se muestra el ejemplo de un informe HTML.
Informar
Cuando el sistema ejecuta los escenarios de prueba como parte de una nueva compilación de desarrollo, suele ejecutarlos en todo su potencial, incluidas todas las pruebas. De un entorno a otro, esto puede llevar algún tiempo, pero le proporciona una amplia visión de cómo la nueva característica puede haber afectado a cualquier otra implementación existente. Podemos evaluar la estabilidad de la construcción a partir del informe de prueba, que el BRM TestToolkit genera al final de una ejecución de prueba. Los informes de prueba contienen detalles para cada escenario de prueba, pero también proporcionan algunas estadísticas y análisis sobre todas las pruebas en general. Podemos utilizar este análisis para encontrar diferencias entre las compilaciones y para asegurarnos de que una compilación funciona correctamente. Vea un ejemplo de informe a continuación.
Conclusión
Contar con la solución de pruebas adecuada puede ahorrarle mucho tiempo y evitar que se produzcan errores innecesarios. Por lo tanto, si se enfrenta a alguna de las dificultades mencionadas en este artículo, o si está interesado en nuestro kit de herramientas BRM de pruebas, no dude en ponerse en contacto con nosotros. Estaremos encantados de contarle más cosas sobre nuestra solución e idear un plan óptimo sobre cómo mejorar su despliegue y flujo de pruebas.