Introduction

Cette page donne une description détaillée de la méthode et la stratégie d'organisation des cas test dans Mostrap dans le contexte du projet LibreOffice.

Structure de base

Dans Moztrap, les cas test peuvent être considérés comme organisés par niveaux hiérarchiques. De haut en bas, les niveaux sont produit, version du produit, session de text, suite de test, cas test. De plus Moztrap fournit des drapeaux permettant de mieux filtrer les cas test lorsqu'on essaie de les exécuter ou de les trier.

Product - L'objet au coeur de Moztrap est le produit. Un produit en lui-même est un peu plus qu'un nom et une description facultative, mais pratiquement tous les autres objets dans le modèle de données Moztrap est relatif à un produit soit directement, soit indirectement.
Product Version - Lorsqu'une nouvelle version de produit est créée, tous les cas test pour ce produit auront une nouvelle version correspondant à la nouvelle version du produit.
Test Run - Une session de test consiste en un ensemble de versions de cas test qui peut être exécuté.
Test Suite - Une suite de test est une collection nommée de cas test qui peut être incluse dans une session de test.
Test Case - Un cas test est un ensemble d'étapes nommé pour tester une seule fonctionnalité ou une caractéristique du système en test. Les cas test sont associés à un produit et peuvent avoir une version par version de produit. Ils peuvent être organisés via des suite et/ou des drapeaux et peuvent avoir des attachements de fichiers. Des préconditions, hypothèses et autres informations préliminaires peuvent être fournies dans la description du cas. Un cas test peut avoir n'importe quel nombre d'étapes ; chaque étape a une instruction et un résultat attendu.
Tag - Un drapeau peut être associé à un ou plusieurs cas test comme un moyen de les organiser et de les filtrer sur plusieurs axes.

Des descriptions plus spécifiques des actions réalisées dans le cadre de LibreOffice sont détaillées dans les sections suivantes.

Produit

Tous les cas test appartiennent à l'unique produit LibreOffice.

Version de produit

Les cas test pour différentes versions de LibreOffice sont divisés en différentes versions du produit. Nous créons de nouvelles versions pour chaque version majeure (3.6, 4.0, 4.1, X.Y, etc.).

Il y a une version spéciale nommée Version 0 dans Moztrap. Créer un nouveau cas test dans cette version permet de l'appliquer à toutes les versions de produit existantes.

Session de test

Une session de test est créée lorsque nous avons besoin d'une itération de tests de régression. Cela arrive habituellement pendant la phase de RC d'une version majeure de LibreOffice (3.6, 4.0, 4.1, X.Y, etc.) ou la mise à jour d'une version mineure (3.6.1, 3.6.2, 3.6.3, X.Y.Z, etc.). La différence réside dans le fait qu'une session de test sur une version majeure peut contenir tous les cas test alors qu'une session de test sur une version mineure ne contient que les tests ayant une priorité élevée uniquement.

Suite de tests

La suite de test porte la priorité que le cas test aura. Dans certains situations spéciales, nous créerons des suites de test pour un objectif particulier. Par exemple, créer une suite de test "4.0 Nouvelles fonctionnalités" portera les cas test particuliers des nouvelles fonctionnalités de la version 4.0, à partir de laquelle nous pourrons créer une session particulière pour le test nécessaire des nouvelles fonctionnalités.

Cas test

Un cas test est un atome concret de la structure de test, comprendre la façon dont un cas test se présente est important et tous les détails sont consultables sur la page test case

Drapeaux

Actuellement, nous définissons deux sortes de drapeaux :

priorité de test - p1, p2, p3, p4
Composants testés - Le composant Libreoffice pour lequel le cas test est créé i.e General/Writer/Calc/Impress/Base/Draw/Math

Vous noterez que le drapeau de priorité semble recouvrir les informations que donne une suite de test. La raison en est qu'ils ont des buts différents. La priorité de la suite de test est là pour permettre la crétion de sessions de test pour des demandes de test particulières. La priorité portant un drapeau ici est pour permettre au cas test d'être filtré facilement lors de l'exécution ou de la gestion des tests.

Termes

Dans cette section, nous expliquons quelques termes généraux utilisés dans le contexte de l'organisation des cas test. Naturellement, ces termes reflètent la structure de tests de base comme mentionnée dans la section ci-dessus.

Type de test

Du fait de processus et d'idée de test complètement différents, nous catégorisons tous les tests dans deux type comme tests de régression et tests de fonctionnalités. Pour en savoir plus à propos des tests de régressions et des tests de fonctionnalité, veuillez consulter les pages regression tests et feature tests.

Priorité

Le but principal de la définition de priorités de tests correctes pour chaque cas test est d'aider à l'exécution des tests dans une mesure raisonnable et pratique en fonction de la situation concrète dans le projet. Par exemple, pafois, exécuter uniquement les cas test P1 et P2 est nécessaire pour les versions bugfix pures, alors que d'autres fois, il sera souhaitable de réaliser les tests de toutes priorités parce que la version contient beaucoup de nouvelles fonctionnalités et d'améliorations.

Actuellement, les tests sont divisés en 4 niveaux de priorité, définis ci-dessous :

P1 test: les tests ayant une priorité urgente ciblent les tests de base, ex. l'installation, le lancement des composants, charger et enregistrer des documents tests, etc. En d'autres mots, ce sont des sortes de smoketest.

P2 test: les tests ayant une haute priorité ciblent les fonctionnalités usuels utilisées par la plupart des utilisateurs, ex. édition de texte, insertion d'images, éléments de dessin, création de tableaux, utilisation des fonctions Calc, création de graphiques, exécution d'une présentation, etc.

P3 test: les tests de priorité moyenne ciblent les fonctionnalités usuelles qui sont utilisées par des utilisateurs plus expérimentés, ex. création de bordures de tableau, définition d'animation entre les diapos, modification des styles de texte, édition du masque des diapos, etc.
P4 test: les tests de priorité basse ciblent les fonctionnalités utilisées par les experts, ex. l'écriture de macros, l'utilisation du Solveur dans Calc, des opérations complexes avec les bases de données.

Dépendance de la langue

LibreOffice peut être utilisé dans différentes locales grâce à son merveilleux mécanisme de localization. La traduction des menus, des boîtes de dialogue et autres chaînes de l'interface offre une expérience d'utilisation plus confortable pour ceux qui ne parlent pas anglais. De plus, certaines fonctionnalités LibreOffice ne sont implémentées que pour certaines langues. Par exemple, le texte Ruby pour les langues asiatiques, l'organisation de l'interface de droite à gauche pour l'hébreu, des correcteurs, des dictionnaires de césure, synonymes et grammaire. Cette attention particulière aux langues a favorisé l'idée de définition de cas test dépendant de la langue.

La plupart de nos cas test ciblent la vérification de fonctionnalités, qui peuvent être partagées par toutes les locales de LibreOffice. Ainsi, la langue de test n'a pas d'importance. Cette sorte de test est définie indépendemment de la locale.

D'un autre côté, comme nous l'avons mentionné au début du paragraphe, la langue de l'interface est traduite et certaines fonctions sont destinées à des utilisateurs qui ne parlent pas anglais. Cela aurait du sens de testes ces aspects dans différentes locales, même si les étapes de vérification apparaîssent similaires dans les différentes langues. Ces types de tests sont définis comme dépendants de la locales.