Test des contraintes de ressources dans les applications composites

Les contraintes de ressources inhérentes aux environnements d'entreprise hétérogènes d'aujourd'hui peuvent entraver la capacité d'une équipe d'assurance qualité / développement à construire des suites de tests. Cela handicape en fin de compte la capacité de l'équipe à fournir et à faire évoluer des applications sécurisées, fiables et conformes dans les délais et dans les limites du budget. Alors que les applications continuent de devenir de plus en plus complexes et certainement plus distribuées, ce problème s'aggrave de manière significative.

Les efforts visant à garantir la qualité des applications hétérogènes d'aujourd'hui sont entravés non seulement par les contraintes de disponibilité des systèmes inhérentes aux architectures distribuées des applications, mais aussi par les contraintes humaines liées à la manière dont ces systèmes sont développés, testés et évolués.

Contraintes système

Les applications hétérogènes d'aujourd'hui impliquent un certain nombre de composants; par exemple, considérez le diagramme suivant d'une architecture d'application d'entreprise commune:

Les efforts pour tester de telles applications sont généralement retardés (et souvent interrompus) car un ou plusieurs composants sont incomplets, évolutifs, instables, inaccessibles ou indisponibles pour les tests. Ces difficultés découlent des contraintes suivantes:

• Accès aux applications distribuées
  Les processus métier sont activés par une interaction complexe de systèmes distribués. Tester un cas d'utilisation qui exploite un seul système est complexe… et si le cas d'utilisation appelle plusieurs systèmes distribués, la complexité augmente de façon exponentielle.
• Accès aux services partenaires
  Les architectures orientées services permettent aux organisations de tirer parti des «unités de travail» distribuées sous forme de services au-delà des frontières organisationnelles. Afin d'exercer des applications internes, l'organisation doit avoir un moyen de modéliser le comportement de ces services (unités de travail) pour tester commodément.
• Accès à des services nouveaux ou en évolution
  Une architecture orientée services introduit une organisation dans un état de changement constant. Du point de vue des tests, cela peut s'avérer très frustrant car l'accès à des services en évolution peut être limité ou totalement indisponible.
• Capacité à simuler les pannes et les problèmes de performances
  Les systèmes orientés services doivent être testés dans des conditions d'échec pour garantir que les applications échouent correctement lorsqu'un composant dépendant ne répond pas ou ne parvient pas à répondre aux mesures de qualité de service requises du point de vue des performances. Si les applications dépendantes sont utilisées ou répliquées, il est très difficile de simuler de telles conditions dans un environnement de test. En outre, il est coûteux de répliquer les systèmes dépendants dans des environnements de test de performance. Par conséquent, il est important de virtualiser les caractéristiques de performance du système dépendant ainsi que ses fonctionnalités métier.

Contraintes humaines

De plus, les contraintes humaines suivantes aggravent la difficulté d'effectuer des tests approfondis avec le calendrier et les ressources donnés:

• Modification des services ou des composants d'application
  L'impact de la modification des services peut avoir des ramifications inconnues si des fonctions spécifiques sont modifiées ou obsolètes. Avoir la capacité de modéliser des tests et d'exécuter des scénarios hypothétiques basés sur les changements planifiés est important pour maintenir le projet sur la bonne voie.
• Délai serré et développement tardif
  C'est un fait bien connu que le développement de logiciels n'est pas une science exacte. Le développement fournit rarement leur application à l'AQ avant la date limite du plan de projet. Avoir la capacité d'émuler la fonctionnalité spécifique au comportement pour créer des suites de régression pour «tester» la fonctionnalité changeante est essentiel pour l'assurance qualité satisfaisant les délais de projet donnés.
• Modifications de dernière minute de l'application
  Les modifications de dernière minute apportées à l'application sont très courantes dans tout cycle de vie de développement logiciel. Le plan de test ne doit pas nécessairement attendre pour exercer l'application dans le contexte des changements prévus.

Surmonter les contraintes de test avec la virtualisation des services

La virtualisation des services est essentielle pour surmonter les contraintes de test dont souffrent les projets de fossés. En simulant des services hors de votre contrôle ou indisponibles, la virtualisation des services permet aux utilisateurs d'accéder à des environnements de test complets et réalistes, permettant aux équipes de développer et de tester leurs applications plus tôt et plus complètement. En appliquant la virtualisation des services dans les environnements de test, les organisations peuvent réduire ou éliminer la dépendance vis-à-vis des dépendances indisponibles, instables ou coûteuses, telles que les services tiers, les bases de données, les mainframes, etc. Parasoft Virtualiser fournit une solution de virtualisation de services intuitive qui facilite la création, la mise à l'échelle et le partage de services virtuels pour les utilisateurs.

L'utilisation de services virtuels signifie une récupération plus rapide du changement aussi rapide (ou plus rapide) que leurs équivalents réels. Les testeurs peuvent utiliser des flux de travail automatisés pour mettre à jour facilement les services virtuels concernés et tester les données si nécessaire. Les outils automatisés peuvent également suivre tous ces changements, avec le contrôle de version en stockant toutes les données pertinentes sous forme de fichiers comparables compatibles avec les systèmes de contrôle de version standard.

Un aspect clé de l'automatisation des tests et de la virtualisation des services est la création et la réutilisation des actifs de test non seulement pour les tests fonctionnels, mais pour d'autres tests critiques tels que les tests de sécurité et de performance. En outre, il est possible de créer rapidement des services virtuels à la volée et de leur injecter une logique métier et des données de test pour prendre en charge le développement d'API locales. Les services virtuels bénéficient d'une configuration basée sur des fichiers, ce qui les rend faciles à partager entre le développement et l'assurance qualité pour la reproduction et le support des défauts.