Lorsque vous avez maintenu votre Oracle BRM (Billing and Revenue Management) depuis un certain temps, vous commencez à vous rendre compte que le nombre d'entités configurées ne cesse d'augmenter. À ce stade, il est très probable que vous ayez également développé quelques personnalisations et que vous ayez intégré d'autres solutions. L'évolution de votre environnement conduit à un ensemble complexe d'objets imbriqués les uns dans les autres. Il arrive un moment où vous, ou votre client, décidez de changer quelque chose. La nouvelle fonctionnalité peut sembler facile à développer à première vue. En réalité, il est très probable qu'elle entre en conflit avec une fonctionnalité existante ou qu'elle nécessite la mise à jour d'une configuration existante. Ce qui semblait être un simple changement affecte alors l'ensemble du système. Il est parfois difficile d'éviter de telles situations, mais le fait d'y être préparé peut vous éviter bien des ennuis. Les scénarios de tests fonctionnels et la polyvalence des tests peuvent changer la donne.
Table des matières
Flux de développement continu
Chez Tridens, nous avons mis en place un flux de développement continu. Toutes nos configurations BRM, personnalisations et autres composants intégrés sont correctement versionnés et suivis sur un système de contrôle de version distribué (Git). Cette pratique permet à nos développeurs de vérifier les versions des composants requis à tout moment et de commencer leur travail. Tout va bien jusqu'à présent, mais comment faire face à la possibilité que de nouvelles fonctionnalités cassent la version actuelle ?
Nous avons mis en place un flux de déploiement et de test qui suit les dépôts distants de nos sources. Par conséquent, chaque fois qu'un développeur apporte des modifications au contrôle de version, le processus de test est lancé. Le flux de déploiement construit des images docker pour tous les composants pertinents avec leurs dernières versions sur un environnement local (ou distant), et des tests automatisés sont exécutés pour s'assurer que la construction est stable. Ce n'est que lorsque les tests sont concluants que nous pouvons mettre les nouvelles versions en production. Ce processus nous permet de nous assurer que les nouvelles fonctionnalités fonctionnent parfaitement avec les fonctionnalités existantes. Les tests exécutés font partie du TestToolkit Oracle BRM, que nous avons développé. Le BRM TestToolkit comporte des étapes et des scénarios prédéfinis avec un code de colle en arrière-plan. Les étapes sont très descriptives et conviviales, ce qui permet à nos développeurs ou à tout autre utilisateur d'écrire rapidement de nouveaux scénarios de test. Vous trouverez un exemple de scénarios de test dans l'image ci-dessous.
BRM TestToolkit pour les tests automatisés
Ce qui a commencé comme de simples scénarios de test pour les créations de comptes et les achats de produits, représente aujourd'hui l'ossature principale de notre test BRM TestToolkit. Pour clarifier, nous avons maintenant plusieurs cas de test différents et des scénarios marginaux pour assurer une couverture maximale des fonctionnalités mises en œuvre. Les tests automatisés permettent à nos développeurs de se concentrer sur la tâche à accomplir et de ne pas consacrer beaucoup de temps aux tests manuels. Bien sûr, il arrive que nous développions une nouvelle fonctionnalité qui n'est pas encore couverte par les scénarios de test. Dans ce cas, les définitions des étapes de test et leur code d'arrière-plan sont implémentés en tant que partie de cette fonctionnalité - pour être utilisés à l'avenir également.
Le TestToolkit peut communiquer avec différents composants, ce qui permet de procéder à des ajustements rapides pour d'autres systèmes également. Nous utilisons également des versions remaniées de notre BRM TestToolkit pour nos autres composants. L'une des dernières fonctionnalités que nous avons ajoutées est la modularité, qui permet aux développeurs d'étiqueter différents scénarios de test en tant que parties d'un groupe. Chaque groupe a alors ses scripts et sa logique séparée, ce qui permet, si on le souhaite, de n'exécuter qu'un nombre spécifique de tests à la fois et en parallèle. En outre, la modularité nous permet de séparer les tests d'évaluation prépayés des tests d'évaluation postpayés ou les tests d'achats complémentaires des achats divers. Vous pouvez voir le déroulement des tests dans l'image ci-dessous.
Couverture des scénarios de test
Le BRM TestToolkit communique avec notre API, que nous avons intégrée à Oracle BRM pour simplifier les opérations les plus complexes. Le TestToolkit peut également interagir avec l'API BRM RestBridgeLes définitions d'étapes de test supportent, entre autres, les opérations suivantes : - le contrôle de la qualité de l'eau - le contrôle de la qualité de l'eau - le contrôle de la qualité de l'eau - le contrôle de la qualité de l'eau - le contrôle de la qualité de l'eau. Les définitions des étapes de test prennent en charge, entre autres, les opérations suivantes :
- Création et gestion de comptes
- Achat d'opérations et autres opérations d'achat d'opérations
- Récupération et vérification de l'équilibre
- Génération de trafic - Événements d'utilisation
- Appels API
- Dépôt du CDR
- outils de trafic en temps réel (protocole diameter)
- Contrôles d'évaluation
- Le BRM TestToolkit compare différents événements d'utilisation et d'achat aux valeurs attendues.
- chaque plan ou produit différent peut avoir son propre ensemble de fichiers de notation, ce qui garantit la polyvalence dans les configurations de produits complexes
En composant les étapes de test conviviales, chaque développeur peut écrire les scénarios pour la fonctionnalité en cours de développement. Dans de nombreux cas, nos développeurs choisissent de mettre en place les scénarios de test à l'avance - avant de développer la fonctionnalité. La préparation des scénarios à l'avance suit le modèle BDD (Behaviour Driven Development). BDD signifie essentiellement que les scénarios dictent le flux de développement et doivent exister à l'avance. Ces scénarios décrivent la manière dont le système doit se comporter, et les développeurs doivent mettre au point de nouvelles fonctionnalités de manière à les adapter à ces scénarios. Nous pouvons exécuter chaque scénario de test séparément, ce qui permet d'obtenir un rapport dans un format spécifique. Vous trouverez ci-dessous un exemple de rapport HTML.
Rapports
Lorsque le système exécute les scénarios de test dans le cadre d'une nouvelle version de développement, il les exécute généralement dans leur intégralité, y compris tous les tests. D'un environnement à l'autre, cela peut prendre un certain temps, mais cela vous permet d'avoir une vue d'ensemble de la manière dont la nouvelle fonctionnalité a pu affecter d'autres implémentations existantes. Nous pouvons évaluer la stabilité de la construction à partir du rapport de test, que BRM TestToolkit génère à la fin d'un cycle de test. Les rapports de test contiennent des détails sur chaque scénario de test, mais aussi des statistiques et des analyses sur l'ensemble des tests. Nous pouvons utiliser cette analyse pour trouver des différences entre les versions et pour nous assurer qu'une version fonctionne correctement. Vous trouverez ci-dessous un exemple de rapport.
Conclusion
La mise en place d'une solution de test adaptée peut vous faire gagner beaucoup de temps et vous permettre d'éviter les bogues inutiles. Par conséquent, si vous rencontrez l'une des difficultés mentionnées dans cet article, ou si vous êtes intéressé par notre kit de test BRM, n'hésitez pas à nous contacter. Nous nous ferons un plaisir de vous en dire plus sur notre solution et de concevoir un plan optimal sur la manière d'améliorer votre déploiement et votre flux de test.
