Pourquoi il est important de tester
Cette rubrique fournit une vue d’ensemble de l’état d’esprit qui conduit à un test insuffisant, décrit les risques associés à l’échec du test des solutions BizTalk et met en contraste les pièges des tests manuels avec les avantages des tests automatisés.
Test en tant que « surcharge »
Malheureusement, avec une demande toujours croissante de retour sur investissement (ROI), la phase de test d’un projet est souvent considérée comme l’un des premiers aspects d’un plan de projet qui peut être réduit.
L’un des arguments contre le test des solutions BizTalk est que « Nous n’avons pas besoin de tester notre solution, car Microsoft teste déjà minutieusement BizTalk Server ». Bien qu’il soit vrai que Microsoft teste soigneusement BizTalk Server, différents scénarios d’utilisation nécessitent l’un des nombreux permutations des besoins métier pour le débit, la haute disponibilité, l’utilisation de l’adaptateur, la latence, les exigences de suivi, l’utilisation de l’orchestration et le code personnalisé. Étant donné que BizTalk Server est extrêmement flexible et peut prendre en charge de nombreux scénarios d’utilisation différents, il n’est tout simplement pas possible d’anticiper et de tester tous ces scénarios. En outre, les paramètres par défaut appliqués dans un environnement de BizTalk Server doivent être optimisés pour prendre en charge chaque scénario d’utilisation. La seule façon de déterminer les paramètres optimaux pour un scénario d’utilisation particulier consiste à tester la solution, à mesurer différents paramètres, à paramétrer l’environnement et à retester. Considérez le diagramme suivant, qui représente un exemple d’architecture physique pour une solution BizTalk Server.
BizTalk physique
Vous pouvez voir dans le diagramme ci-dessus que la solution BizTalk Server contient de nombreuses parties mobiles, notamment plusieurs ordinateurs exécutant des BizTalk Server, des ordinateurs exécutant des SQL Server, des nœuds de cluster de serveur et des domaines Active Directory. Une fois le système opérationnel, de nombreux ajustements de configuration seront appliqués pour optimiser l’application en fonction des besoins de l’entreprise, afin d’optimiser le retour sur investissement global de la solution. Ce scénario unique montre qu’il existe de nombreuses variables en jeu. En plus de l’architecture physique de l’environnement, considérez le diagramme suivant, qui illustre le flux d’un message à travers BizTalk Server.
Sample Logical BizTalk Message Flow
Lorsque nous examinons le diagramme logique d’un message transitant par BizTalk Server, nous voyons d’autres variables qui nécessitent des tests par projet, notamment des composants de pipeline d’envoi et de réception personnalisés et des classes personnalisées qui peuvent être appelées à partir d’orchestrations BizTalk. Étant donné que la complexité et l’utilisation de types de composants personnalisés et de composants BizTalk varient d’un projet à l’autre, il devient plus évident pourquoi il est important d’effectuer des tests pour chaque scénario d’utilisation spécifique.
Méthodologie et chronologie des tests
Pour garantir l’efficacité et l’efficacité des tests, le harnais de test doit être entièrement automatisé afin d’être facilement reproductible et de réduire les risques d’erreur humaine. De plus, il convient de prévoir suffisamment de temps pour les tests lors de la planification du projet. Une approche minimaliste des tests comprendrait des étapes manuelles similaires à ce qui suit :
Chargez manuellement un ou plusieurs messages dans un point de terminaison de réception, tel qu’une suppression de fichiers ou à l’aide d’un client SOAP pour appeler un service Web.
Validez manuellement le contenu et la structure corrects d’un message. Étant donné que plusieurs schémas sont souvent présents dans un projet, les messages peuvent être un mélange de fichier plat et de XML et peuvent également contenir des dépendances entre champs.
Notes
Un exemple de ceci serait n’importe quel projet impliquant des messages SWIFT. Il s’agit de messages de fichiers plats qui ont des dépendances entre champs. Autrement dit, la valeur d’un champ dépend d’un autre . La simple validation XSD ne se fera pas ici ; par conséquent, l’accélérateur SWIFT utilise le moteur de règles BizTalk pour la validation des messages. Pour plus d’informations sur l’accélérateur SWIFT.
Case activée manuellement les journaux des événements sur les ordinateurs BizTalk Server en cas d’erreurs.
Manuellement case activée les bases de données BAM (le cas échéant) pour vérifier que les informations d’activité sont enregistrées correctement.
L’utilisation d’un processus manuel comme décrit ci-dessus pour les tests est subjective et sujette aux erreurs. Envisagez d’examiner un message SWIFT de cent lignes avec des dépendances inter-champs pour 10 cas de test différents. La plupart des développeurs de projets ne seraient pas en mesure de le faire ou, même s’ils en étaient capables, ne seraient pas enclins à s’engager dans une telle tâche de manière fiable et précise. L’implémentation d’un processus de test subjectif, manuel et sujet aux erreurs ajoute des risques à un projet et augmente les risques d’échec.
Le risque d’échec est souvent amplifié par des délais de planification de projet qui n’intègrent pas suffisamment de temps pour les tests. Trop souvent, une stratégie de test de projet repose sur une seule passe de test manuelle qui est planifiée une semaine environ avant la date de mise en production. Ces tests limités exposent le projet à un risque. Étant donné une telle chronologie limitée pour les tests, si des problèmes sont détectés, le projet peut être retardé, car aucun temps n’a été alloué pour résoudre les problèmes. En outre, si un problème est détecté et résolu, il se peut qu’il ne reste pas suffisamment de temps pour effectuer les tests suivants avant que le système ne soit mis en service.
La réalité du test « build final unique, passe de test unique, prenez le projet en direct » est qu’il entraîne souvent le retard du projet, le projet dépasse le budget, ou pire encore, le projet échoue complètement ! Pour les systèmes stratégiques, ce type de méthodologie de test est une catastrophe qui attend de se produire.
Tester efficacement et efficacement
Étant donné que les tests appropriés sont souvent vus comme un luxe coûteux plutôt qu’une exigence intégrale, ils sont trop souvent mis sur la fin d’un projet. Compte tenu de la complexité de la pile logicielle et matérielle utilisée dans des environnements d’entreprise hétérogènes, cette approche n’est pas réaliste. L’implémentation d’une approche de test automatisée qui peut être réexécuter à la demande est la meilleure façon de tester efficacement et efficacement et fait partie intégrante des projets réussis qui, en fin de compte, fournissent un excellent retour sur investissement pour l’entreprise. En investissant au début du projet dans des tests fonctionnels complets de bout en bout pour chaque chemin de code via le système, vous générez des ressources de test. Ces actifs nécessitent des investissements (c’est-à-dire du temps de développement) afin de tirer parti de l’efficacité et de l’efficience accrues des tests par la suite. Pour réduire l’investissement nécessaire au projet pour dériver une telle infrastructure, nous vous recommandons d’utiliser l’infrastructure de test de charge Visual Studio 2010. Visual Studio 2010 inclut la majorité des étapes de test courantes requises pour un test réussi et est l’infrastructure utilisée dans les scénarios de test présentés plus loin dans ce guide.