Automatisation du processus de création
Un processus de génération automatisé compile, déploie, puis exécute des tests de vérification de build (BVT) sur le code source le plus récent pour un projet à intervalles réguliers et prédéterminés. Ensuite, un « rapport de génération », qui détaille la réussite ou l’échec du processus de génération, est diffusé aux parties prenantes du projet. Le rapport de génération est analysé pour déterminer quelles zones du projet doivent être prises en compte et si le projet doit être restauré vers une version/build antérieure.
La puissance d’un processus de génération automatisé est qu’il peut être planifié pour être exécuté pendant les « heures creuses ». De cette façon, il peut aider à garantir la stabilité du projet sans prendre des cycles directement en dehors du temps de développement. Cette rubrique fournit une vue d’ensemble du processus de génération, décrit comment les tests de vérification de build s’intègrent dans le processus de génération, décrit les aspects des tests fonctionnels utilisés pendant les tests de vérification de build et fournit des informations sur l’importance de l’automatisation du processus de génération.
Vue d’ensemble du processus de génération
Avant d’examiner les spécificités des tests, il est important de prendre en compte le contexte de la façon dont les tests s’intègrent dans le processus de génération global. Tous les groupes de produits de Microsoft fonctionnent selon la philosophie selon laquelle le processus de génération est le pulsation de tout projet logiciel. Cette approche est également utilisée par bon nombre des plus grands cabinets de conseil au monde qui créent des solutions stratégiques sur la pile de logiciels Microsoft. Sans une pulsation régulière et une case activée régulière de celle-ci, il est impossible de connaître l’intégrité du projet. Pour s’assurer que les groupes de produits disposent d’un aperçu continu de l’intégrité globale du projet, le processus de génération est exécuté quotidiennement, généralement à minuit. Les étapes suivantes résument un processus de génération automatisé classique :
Obtenez la dernière version du code source à partir du référentiel de code source.
Compilez le code source.
Emballez des fichiers binaires pour le déploiement, généralement à l’aide de scripts ou de fichiers Microsoft Windows Installer.
Déployez le projet sur un serveur de test.
Exécutez automatiquement un ensemble complet de tests de vérification de build (BVTs).
Publiez un rapport de build détaillé pour les membres de l’équipe de projet.
Notes
Les bvT sont des tests fonctionnels qui exercent les fonctionnalités main de la solution pour tester sa qualité. Vous devez vous assurer que vos BVT sont suffisamment complets pour évaluer la qualité de la build, mais assez petits pour s’exécuter dans le temps de génération quotidien alloué !
Notes
Vous devez également traiter les scripts ou processus de déploiement, d’annulation de déploiement, de configuration et d’installation dans le cadre du projet logiciel à des fins de test. Les opérations du projet, ainsi que son déploiement et sa configuration, doivent être testées.
Ce processus est généralement terminé tôt le matin vers 6 heures du matin, ce qui permet aux premiers membres de l’équipe de commencer à travailler sur la nouvelle build du jour. Si une ou plusieurs des BPP de la nuit précédente ont échoué, il est de la responsabilité de l’équipe de le corriger dès que possible.
Suivre un processus de génération quotidien présente de nombreux avantages pour le projet. Tout d’abord, il fournit une pulsation régulière (composée de la build quotidienne plus les BVT automatisés). Deuxièmement, l’utilisation de BVTs force l’intégration aux systèmes, ce qui est une tâche difficile, et le fait de le faire tôt en soi réduit les risques du projet. En raison du temps nécessaire à leur exécution, les tests de stress et de performances sont généralement effectués en dehors du processus de génération quotidien. Les tests de contrainte et de performances sont généralement planifiés pour être exécutés sur une build jalon dans le projet.
Le processus de génération quotidien peut être, et a été utilisé, très efficacement sur les solutions BizTalk. Toutefois, vous devez vous assurer que les tâches qui sont généralement laissées à la fin dans les projets sont effectuées de manière itérative dès le début. Par exemple, le déploiement dans BizTalk Server n’est certainement pas trivial. Il est important que les scripts de déploiement automatisé soient développés à l’avance. Si vous ne le faites pas, vous allez déployer et annuler manuellement le déploiement de la solution plusieurs fois tout au long du projet, ce qui vous coûtera plus de temps au final. Il existe des outils disponibles pour piloter le processus de génération quotidien ; Visual Studio Team System et Team Foundation Server sont le choix principal pour de nombreuses personnes. Les scripts MSBuild peuvent être utilisés pour piloter les étapes du processus de génération.
Notes
L’utilisation de cet outil n’est pas prise en charge par Microsoft, et Microsoft n’offre aucune garantie quant à l’adéquation de ces programmes. L'utilisation de ce programme relève de votre seule responsabilité.
Pour plus d’informations sur l’automatisation des tests à l’aide du Gestionnaire de tests Microsoft, consultez Exécution de tests automatisés.
Test de vérification de build
Le test de vérification de build comprend généralement les éléments suivants :
Tests unitaires : étant donné que les tests unitaires sont généralement les premiers tests à développer, ils doivent idéalement être créés avant l’écriture du code, si vous utilisez vraiment une approche de développement pilotée par les tests. En les ajoutant aux bvts pendant les premières étapes d’un projet, vous fournissez au moins une couverture du code immédiatement. À mesure que le nombre de tests fonctionnels et, par conséquent, la couverture des tests augmente, vous pouvez choisir de supprimer les tests unitaires des TPP.
Tests de fumée : tests fonctionnels de bout en bout qui testent les fonctionnalités de base de votre solution. Si ceux-ci échouent, quelque chose ne va pas sérieusement. Celles-ci peuvent généralement être exécutées relativement rapidement.
Tests fonctionnels : ils ciblent également des scénarios de bout en bout, mais dans ce cas, ils testent tous les scénarios du projet. Pour les grands projets, il peut être judicieux de classer davantage vos tests fonctionnels (pour instance, pour permettre à un composant particulier d’être testé rapidement, de manière fiable et isolée). Ces tests fonctionnels doivent être verrouillés une fois que vous avez signé votre solution comme étant fonctionnellement correcte.
Tests de vérification de régression : chaque fois qu’un bogue de solution est trouvé et corrigé, des cas de test de vérification de régression doivent être ajoutés pour vérifier que le bogue est corrigé et qu’il n’est pas réintroduit plus tard dans le cycle de vie du projet. Ces tests sont généralement des cas qui n’ont pas été abordés dans les cas de test fonctionnel. Vous devez vous attendre à ce que vos tests de vérification de régression augmentent en nombre même après la mise en service de la solution, si de nouveaux bogues sont découverts et corrigés.
Sur de très grands projets, vous devrez peut-être faire de vos BVT un sous-ensemble de la suite de tests fonctionnels complète (en raison de la durée d’exécution nécessaire). Pour les petits projets, les BPP constituent l’ensemble. Évidemment, si vous souhaitez intégrer les BVT dans le cadre de votre build quotidienne, l’ensemble du processus doit être automatisé. Dans le reste de cette rubrique, nous allons nous concentrer sur la façon dont vous pouvez utiliser BizUnit et d’autres outils pour y parvenir.
Test fonctionnel
Dans le contexte des tests fonctionnels des applications BizTalk, testez un scénario de bout en bout spécifique. Lorsque vous effectuez ce type de test, il est utile d’imaginer BizTalk Server comme une boîte noire que vous testez fonctionnellement d’un point de vue externe. Par exemple, un test peut impliquer l’alimentation d’un message d’entrée (avec des valeurs connues) à un point de terminaison d’emplacement de réception (par exemple, URL, emplacement FTP, quel que soit votre choix de transport). Le test surveillerait ensuite le nombre correct de messages avec la sortie correcte générée côté envoi. Cela peut sembler relativement simple. Toutefois, lorsque vous considérez que certains scénarios nécessitent des entrées dans un certain ordre et à un certain moment, et que vous ajoutez cela à d’autres exigences de solution (par exemple, lors de l’enregistrement des données de suivi dans BAM), il devient clair qu’un outil et une infrastructure peuvent être utilisés pour orchestrer cela.
Il est essentiel que les tests fonctionnels sont conçus pour couvrir tous les chemins possibles de votre solution. Cela doit inclure non seulement les scénarios que vous attendez en production, mais également les chemins d’accès d’échec et de gestion des exceptions que vous avez implémentés mais que vous espérez ne jamais utiliser. Une expression couramment utilisée pour décrire cela est le test pour le « scénario de mauvais jour ». Vous devez vous assurer que toutes les orchestrations, tous les types de messages autorisés et toutes les branches de code sont exercés par votre suite de tests fonctionnels. Les sections suivantes décrivent le développement de cas de test fonctionnel positifs et négatifs pour couvrir tous les chemins de code.
Pour plus d’informations sur les tests fonctionnels et les autres catégories de tests qui doivent être implémentées avant de mettre une solution BizTalk Server en production, consultez Check-list : Test Operational Readiness.
Tests positifs
Lors de l’exécution de tests positifs, il est important de s’assurer que toutes les combinaisons de messages, de pipelines, d’orchestrations et de points de terminaison sont passées par la solution afin que tous les flux de messages soient exécutés. Pour vérifier que vous testez tous les chemins de code, vous devrez probablement traiter différents messages avec un contenu différent.
Lors du test, utilisez le type de transport qui sera utilisé en production. Malheureusement, trop souvent, les tests fonctionnels sont effectués uniquement à l’aide de l’adaptateur de fichier lorsqu’un autre transport sera utilisé en production. L’adoption de cette approche vous met en place, vous et le projet global, en cas d’échec ultérieurement.
Validez la charge utile de tous les messages envoyés à partir du système. Si les messages sont XML, vous devez valider leurs champs de schéma et de clé dans le message à l’aide d’expressions XPath.
Valider toutes les données de suivi stockées dans BAM (si elles sont utilisées) ; toutes les autres données restantes dans des référentiels de données externes doivent être prises en compte.
Testez l’exécution de toutes les stratégies et règles du moteur de règles métiers (BRE) si votre solution utilise BRE.
Tests négatifs
Vérifiez que vous testez la gestion des messages non valides via votre système. Vous devez vérifier que la stratégie que vous avez choisie (les rejeter avant qu’elles ne soient BizTalk Server, ou les suspendre) a fonctionné correctement.
Lorsque vous testez la gestion des messages non valides, vérifiez que toutes les orchestrations de gestion des erreurs côté réception ont été implémentées pour gérer les messages suspendus.
Assurez-vous que vos scénarios d’échec couvrent tous les blocs d’exceptions dans vos orchestrations. L’échec du test est un problème courant.
Si vous utilisez des transactions de longue durée avec un comportement de compensation, testez ces scénarios avec soin. Il s’agit d’un autre domaine où des tests inadéquats entraîneront de graves conséquences dans un environnement de production.
Vérifiez que les échecs sont correctement consignés dans les journaux d’erreurs appropriés.
L’automatisation est essentielle
Pour effectuer tout cela de manière efficace et efficace, consacrez du temps d’avance à l’automatisation des tests. Les tests manuels sont fastidieux, sujets aux erreurs et coûteux (en termes de temps et de coût). Chaque fois que vous effectuez une passe de test manuelle, vous ajoutez un autre lot de tâches qui doivent être gérées par les ressources du projet (personnes de l’équipe). En automatisant cela à l’avance, vous pouvez obtenir un retour sur l’investissement initial requis pour développer les tests chaque fois qu’ils sont exécutés. Les bons tests fonctionnels doivent s’exécuter rapidement et efficacement et être reproductibles ; chaque test doit également être autonome (il doit être indépendant de tout autre test ; l’adoption de cette approche vous permet d’exécuter plusieurs tests séquentiellement en tant que suite de tests.) Les tests fonctionnels doivent toujours produire le même résultat. Des tests fonctionnels mal écrits ou du code mal écrit entraînent des résultats différents entre les séries de tests, ce qui entraîne une confusion et une perte de temps pour examiner la cause racine de l’échec.
Il est important de réduire au minimum l’effort de développement requis pour écrire chaque test fonctionnel. Généralement, plus il est coûteux de produire quelque chose (en termes de temps de développement), moins vous risquez de rencontrer de cas de test. Cela signifie que vous aurez un niveau de couverture de test inférieur à celui de votre code. En utilisant une infrastructure de test, vous pouvez développer des cas de test plus rapidement et plus facilement et, par conséquent, faciliter l’obtention d’une couverture complète du code. La plupart des bonnes infrastructures de test utilisent une approche déclarative pour définir des tests. (Autrement dit, la configuration d’un test est stockée dans un fichier de configuration, qui est généralement un fichier XML.) L’utilisation d’une bonne infrastructure de test vous permet de développer une suite de tests fonctionnelle complète de manière agile et fiable et évite d’avoir à « réinventer la roue » encore et encore, pour ainsi dire.
Prise en charge MSBUILD pour les projets BizTalk Server
BizTalk Server prend en charge la plateforme Microsoft Build Engine (MSBUILD), qui prend en charge la création de projets managés dans des environnements de labo de build où Visual Studio n’est pas installé. MSBUILD prend en charge la création de projets à partir d’une ligne de commande et de fonctionnalités avancées, notamment la journalisation et le traitement par lots MSBUILD. Pour plus d’informations sur MSBUILD, consultez Vue d’ensemble de MSBuild.