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.
Si vous n'avez jamais utilisé de système de gestion de configuration de logiciels ou n'êtes pas familiarisé avec ce concept, 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 un actif de test essentiel.
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 configuration 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.
L'intégration de ClearCase ou de Rational Team Concert pour la gestion des versions des actifs de test de Functional Tester 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 ou de Rational Team Concert 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.
ClearCase :
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 actifs de test Functional Tester.
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 unifiée des changements (UCM) 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.
Dans ClearCase, 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 configuration 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.
Rational Team Concert :
Vous pouvez utiliser un contrôle des sources Jazz pour gérer un code source, des documents et d'autres artefacts que vous souhaitez placer sous un contrôle de version et partager avec une équipe. Un contrôle des sources Jazz est intimement intégré à d'autres outils du cycle de vie de développement d'application inclus dans Rational Team Concert.
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.