La gestion de configurations de logiciels regroupe le contrôle des sources, la gestion des changements et le contrôle des versions.
Les systèmes de gestion de configurations de logiciels sont couramment utilisés dans les équipes de développement dont les membres travaillent en même temps sur un même jeu de fichiers. Si deux développeurs modifient le même fichier, l'un d'eux risque de remplacer accidentellement les modifications apportées par l'autre. Les systèmes de gestion de configurations de logiciels sont conçus pour éviter cet incident inhérent au partage de fichiers dans un environnement multi-utilisateur.
Tout système de gestion de configurations de logiciels crée un référentiel central pour faciliter le partage des fichiers. Chaque fichier à partager doit être ajouté au référentiel central afin d'en créer la première version. Une fois que le fichier fait partie du référentiel central, les utilisateurs peuvent y accéder et le mettre à jour, créant ainsi de nouvelles versions.
Une opération d'extraction (checkout) crée une copie locale du fichier dans laquelle vous pouvez apporter des modifications. Une fois satisfait de votre travail, vous archivez (checkin) le fichier pour en créer une nouvelle version. La version originale du fichier existe toujours.
Dans un environnement multi-utilisateur, il va de soi que plusieurs utilisateurs peuvent extraire le même fichier en même temps. Lorsque cela arrive, une fonction spéciale du logiciel de gestion de configurations de logiciels appelée "fusion" est disponible pour combiner les multiples changements dans un même fichier. Le premier utilisateur à archiver le fichier crée la nouvelle version. Le deuxième utilisateur à archiver le fichier doit fusionner ses modifications dans cette version. Si le système de gestion peut combiner les modifications, il les fusionne dans une nouvelle version du fichier. Si les modifications s'opposent ou ne peuvent être résolues par le système de gestion, les conflits doivent être résolus manuellement.
Si vous n'avez jamais utilisé de système de gestion de configurations de logiciels ou n'êtes pas familiarisé avec ses concepts, vous vous demandez peut-être si cette solution est appropriée à votre projet. L'automatisation des tests est un travail de développement non négligeable. Chaque fois qu'un script de test est créé, que ce soit par enregistrement ou par codage, un fichier est généré, qui contient du code. Ce code devient dès lors une ressource de test essentielle.
Dans un environnement coopératif, le fait que le travail d'un membre de l'équipe puisse être "écrasé" accidentellement par un autre membre induit un risque de perte de code fonctionnel ou d'endommagement des scripts de test. Un système de gestion de configurations de logiciels offre un moyen d'éviter ce risque. Chaque fois qu'un fichier change, une nouvelle version est créée et le fichier original est préservé.
Toutes les fonctions essentielles à la gestion des versions des scripts de test sont disponibles à travers l'interface de Functional Tester, atout majeur pour les équipes qui découvrent la gestion des configurations de logiciels. Cette intégration simplifie l'adoption d'un tel système de gestion.
Une équipe qui connaît déjà les fonctions et les avantages de la gestion de configurations de logiciels pourra préférer l'implémentation de ClearCase avec Functional Tester afin de bénéficier de certaines fonctions avancées qui ne sont accessibles qu'à l'aide des outils ClearCase.
En un mot, ClearCase.
L'intégration de ClearCase avec Functional Tester pour la gestion des versions des ressources de test est très spécifique et ne peut pas être reproduite avec d'autres outils. Pour cette raison, certaines opérations ClearCase ne peuvent pas être effectuées en dehors de Functional Tester.
Lorsque vous utilisez Functional Tester, les opérations ClearCase semblent très simples. En réalité, un grand nombre d'opérations complexes se déroulent en arrière-plan. Un script Functional Tester est une collection de fichiers. La difficulté que représente le traitement de plusieurs fichiers en tant qu'entité unique est masquée, car toutes les actions entreprises dans l'interface utilisateur de Functional Tester portent sur le script dans sa globalité. Aucun des fichiers apparentés au script n'est visible dans l'interface utilisateur. En outre, certaines opérations de gestion des configurations, telles que la fusion des fichiers, sont particulièrement complexes. Une logique intégrée détermine l'ordre dans lequel les fichiers sont fusionnés, puis différents utilitaires sont mis à contribution selon les besoins pour effectuer la fusion proprement dite.
L'intégration de Functional Tester avec ClearCase fournit toutes les fonctions élémentaires de gestion des configurations de logiciels et masque la complexité de la structure des ressources de test Functional Tester. Un tel niveau d'intégration ne peut pas être obtenu en utilisant ClearCase en dehors de Functional Tester ni en utilisant un autre système de gestion de configurations de logiciels.
Par ailleurs, si un utilisateur tente des opérations sur des fichiers Functional Tester en dehors de l'interface utilisateur de ce dernier, les scripts correspondants peuvent ne plus être synchronisés avec leurs fichiers apparentés et devenir inutilisables.
Functional Tester fonctionne dans une vue ClearCase activée pour la gestion UCM (Unified Change Management) si cette vue a été créée dans le cadre d'un projet UCM à flux unique. Functional Tester ne fonctionne pas dans les vues qui font partie de projets UCM multiflux.
Un objet script de test Functional Tester inclut généralement les fichiers suivants :
Ce fichier est créé par enregistrement.
A chaque script est associé un fichier auxiliaire qui est généré après l'enregistrement.
Chaque script comprend un fichier de mappe. Celui-ci peut être associé soit à un seul script (*. rftxmap) ou partagé entre plusieurs scripts (*. rftmap). Pour éviter aux utilisateurs de confondre les mappes privées et les mappes partagées, les suffixes des noms de fichier sont différents.
Chaque script peut aussi comprendre un ou plusieurs fichiers de point de vérification. Ces fichiers ne sont jamais partagés entre plusieurs scripts.
Chaque script comporte un fichier de définition. Celui-ci contient le nom du fichier de mappe, le nom du script, les noms de tous les objets reconnus et d'autres informations de liaison des fichiers.
Vous pouvez associer un pool de données de test public ou privé à un
script de test.
Les pools publics peuvent être associés à plusieurs scripts.