Cette table permet à l’utilisateur de filtrer les fiches de test avant leur visualisation. Si elles sont sélectionnées, leurs données sont affichées. Pour modifier les données présentées, cocher ou décocher, cliquer sur Filtre et sélectionner le niveau des données voulues depuis l’arborescence.
"; // testPlan.html $TLS_hlp_testPlan = "Une campagne de test est une approche systématique pour tester un système ou un logiciel. Il est possible d’organiser l’activité de test avec des versions du produit, des plateformes pour tracer les résultats.
Cette section permet l'administration des campagnes de test. Administrer les campagnes de test implique la création/modification/suppression de campagnes, l’ajout/modification/suppression de version du produit pour chaque campagne et l’ajout/modification/suppression d'indicateurs d'avancement.
Cette section permet la définition du contenu d'une campagne de test. Gérer le contenu d'une campagne de test implique la définition des platesformes utilisées dans la campagne, la définition des fiches de test utilisées dans la campagne, l'assignation éventuelle des fiches de test à des utilisateurs liés à la campagne et la définition de l'urgence des tests. Au cours de la réalisation, les versions de fiches de tests peuvent également être mises à jour si de nouvelles versions de fiches de tests ont été créées.
Cette section est celle où les utilisateurs peuvent exécuter les fiches de test (écrire des résultats de test) et imprimer les suites de test de la campagne de test. Cette section est où les utilisateurs peuvent tracer les résultats de leur exécution de fiches de test.
Remarque: Il est possible que les utilisateurs puissent ne pas voir de liste déroulante avec les campagnes de test. Dans ce cas, tous les liens (sauf ceux actifs pour le test leader) seront indisponibles. Si tel est le cas, veuillez contacter le test leader ou l’administrateur pour vous donner les droits du projet qui convienne ou pour vous créer une campagne de test.
"; // custom_fields.html $TLS_hlp_customFields = "Les points suivants sont des éléments sur l’implémentation des champs personnalisés:
La définition des champs personnalisés comprend les attributs logiques suivants:
Permet aux utilisateurs d’exécuter les fiches de test. L’exécution en elle-même n’est qu’une assignation à chaque version d'une fiche de test d’un résultat (réussi, en échec, bloqué) pour une version du produit (livraison) donnée.
L’accès à un système de gestion d’anomalie peut être configuré. L’utilisateur peut alors ajouter directement de nouvelles anomalies et rechercher celles existantes. Voir le manuel d’installation pour d’avantage de détails.
"; //bug_add.html $TLS_hlp_btsIntegration = "(Seulement si c’est configuré) TestLink a une intégration très simple avec les systèmes de gestion d’anomalies, qui n’est ni capable d’envoyer de requête de création au système, ni récupérer le bug id. L’intégration est faite par des liens aux pages du système de gestion d’anomalie, qui appelle les fonctionnalités suivantes:
Les propriétés permettent de sélectionner la campagne de test, le Build et la plateforme (si disponible) à exécuter.
Il est possible de choisir la campagne de test voulue, conditionnant l’affichage des versions du produit correspondantes, et réinitialisant les filtres de campagne de test.
Si la fonctionnalité de gestion des plateformes est utilisée, il est nécessaire de sélectionner la plateforme appropriée avant l’exécution.
Il est possible de choisir la version du produit pour en exécuter les fiches de test.
Les filtres fournissent la possibilité de modifier la série de fiches de test affichées avant exécution, et d’en réduire la liste en appliquant les filtres avec le bouton \"Appliquer\".
Les filtres avancés permet de spécifier une liste de valeurs pour les filtres en utilisant CTRL-Clic dans la liste multi-sélection.
Il est possible de filtrer les fiches de test par mots-clés qui leurs ont été affectés. Il est possible de choisir plusieurs mots-clés en utilisant CTRL-Clic. Si vous choisissez plus d’un mot-clé, vous pouvez choisir le mode \"And\" ou \"Or\" pour le filtre.
Il est possible de filtrer les fiches de test par priorité, \"Criticité de fiches de test\" combiné à \"Urgence de test\" dans la campagne de test courante.
Il est possible de filtrer les fiches de test affectées ou non à quelqu’un, et également à un utilisateur spécifique (avec inclusion des fiches non affectés ou non - les filtres avancés sont disponibles).
Il est possible de filtrer les fiches de test par résultat(les filtres avancés sont disponibles), sur la version du produit choisi pour l’exécution, sur la dernière exécution, sur tous les versions du produit, n’importe quel version du produit ou sur une version du produit spécifique.
"; // newest_tcversions.html $TLS_hlp_planTcModified = "Toute la série des fiches de test liées à une campagne de test est analysée, et la liste des fiches de test qui ont une nouvelle version disponible est affichée (par rapport aux versions courantes liées à la campagne de test).
"; // requirementsCoverage.html $TLS_hlp_requirementsCoverage = "La fonctionnalité permet de cartographier la couverture des exigences utilisateur ou système par fiche de test.
Les exigences sont regroupées dans des dossiers d’exigences qui sont liés au projet de test.
TestLink ne supporte pas les versions des dossiers d’exigences et en même temps des exigences: il faut d’abord faire une version d’exigence avec d’effectuer celle du dossier.Titre. Un utilisateur peut ajouter une simple description ou des notes au champ Périmètre.
Le comptage surchargé d’exigences sert d’évaluation à la couverture d’exigences dans le cas où toutes les exigences ne sont pas ajoutées (importées). La valeur 0 signifie que le comptage courant d’exigences est utilisé pour les métriques.
Par exemple: le dossier d’exigences compte 200 exigences mais seulement 50 sont ajoutées dans Testlink. La couverture est de 25% (si toutes les exigences ajoutées sont testées).
Cliquer sur le titre des dossiers d’exigences créés. il est possible de créer, modifier, supprimer ou importer les exigences du cahier de test. Chaque exigence a un titre, un contexte et un statut. Le statut peut être \"Normal\" ou \"Non testable\". Les exigences non testables ne sont pas comptées dans les métriques. Ce paramètre peut être utilisé pour des fonctionnalités non implémentées et des exigences mal conçues.
Il est possible de créer de nouvelles fiches de test pour les exigences en utilisant l’action multiple avec les exigences sélectionnées dans l’écran du cahier. Les fiches de test sont créés dans le dossier de test avec le nom défini en configuration (par défaut: $tlCfg->req_cfg->default_testsuite_name = \"Test suite created by Requirement - Auto\";). Le titre et le contexte sont copiés dans le cas de test.
"; $TLS_hlp_req_coverage_table = "Les liens internes permettent de créer des liens vers d’autres exigences ou dossiers d’exigences avec une syntaxe spéciale. Le comportement des liens internes peuvent être changé dans le fichier de configuration.
Utilisation:
Lien vers des exigences: [req]req_doc_id[/req]
Lien vers des dossiers d’exigences: [req_spec]req_spec_doc_id[/req_spec]
Le projet de test des exigences/dossiers d’exigences et une ancre pour sauter peut aussi être spécifié:
[req tproj=<tproj_prefix> anchor=<anchor_name>]req_doc_id[/req]
Cette syntaxe fonctionne également pour les dossiers d’exigences.
Pour toute modification, Testlink demande un message de log servant à la traçabilité. Si le périmètre de l’exigence a été modifié, vous être libre de choisir de créer ou non une nouvelle révision. Quand toute autre modification est apportée, la création d’une nouvelle révision est obligatoire.
"; // req_view $TLS_hlp_req_view = "Pour facilement partager le document avec d’autres personnes, cliquer tout simplement sur l’icône globe en haut du document pour créer un lien direct.
La fonctionnalité permet de comparer les révisions/versions d’exigences si plusieurs révisions/versions de l’exigence existent. Le récapitulatif fournit le message de log pour chaque révision/version, un horodatage et l’auteur de la dernière modification.
Affiche toutes les fiches de test liés à l’exigence courante.
Les relations d’exigence sont utilisées pour modéliser les relations entre les exigences. Les relations personnalisées et l’option pour autoriser les relations entre exigences de différents projets de test peuvent être configurées dans le fichier de configuration. Si vous définissez une relation \"Exigence A est parent de Exigence B\", Testlink définit implicitement la relation \"Exigence B est enfant de Exigence A\".
"; // req_spec_edit $TLS_hlp_req_spec_edit = "Les liens internes permettent de créer des liens vers d’autres exigences/dossiers d’exigences avec une syntaxe spéciale. Le comportement des liens internes peut être modifié dans le fichier de configuration.
Utilisation:
Lien vers des exigences: [req]req_doc_id[/req]
Lien vers des dossiers d’exigences: [req_spec]req_spec_doc_id[/req_spec]
Le projet de test des exigences/dossiers d’exigences, une version et une ancre pour sauter peut aussi être spécifié:
[req tproj=<tproj_prefix> anchor=<anchor_name>version=<version_number>]req_doc_id[/req]
Cette syntaxe fonctionne également pour les dossiers d’exigences (l’attribut de version n’a aucun effet).
Si vous ne voulez pas définir une version, l’exigence avec toutes ses versions est affichée.