meta données pour cette page
Différences
Ci-dessous, les différences entre deux révisions de la page.
| Prochaine révision | Révision précédente | ||
| certif:procedure:test [2025/07/15 11:53] – créée - modification externe 127.0.0.1 | certif:procedure:test [2026/09/29 10:10] (Version actuelle) – supprimée nicolas | ||
|---|---|---|---|
| Ligne 1: | Ligne 1: | ||
| - | ====== Procédure de test (procédure #11) ====== | ||
| - | |||
| - | ===== Informations qualité ===== | ||
| - | |||
| - | |**Suivi des modifications majeures** |oct. 2023 Passage des tests dans la carto fonctionnelle\\ aout 2017 Migration sur DoKuWiKi et refonte complète pour v9\\ déc. 2015 - Nicolas Marchand - Création du document | | ||
| - | |**Suivi des approbations** |Ce document correspond à l' | ||
| - | |**Objet** |L' | ||
| - | |**Destinataires** |**- Validation des modifications : ** Gérant \\ **- Approbation du document** : Equipe dev & Equipe Assistance| | ||
| - | |||
| - | ===== Liens rapides aux documents liés ===== | ||
| - | A partir de septembre 2023 les tests d' | ||
| - | [[: | ||
| - | [[: | ||
| - | |||
| - | ===== Les différents types de test ===== | ||
| - | |||
| - | ==== Tests d' | ||
| - | Les tests d' | ||
| - | On distinguera trois types de tests d' | ||
| - | * Les tests liés au respect des règles de la marque NF | ||
| - | * Les tests de non-régression | ||
| - | * Les tests spécifiques aux besoins d'un client | ||
| - | Ils sont définis dans directement dans la [[https:// | ||
| - | === Qui passe ces tests === | ||
| - | Les tests sont passés par l' | ||
| - | === Comment passer ces tests === | ||
| - | - Ce connecter à la [[https:// | ||
| - | - Aller dans l'ergo " | ||
| - | - Choisir le test à passer | ||
| - | == Cas d'un test passé pour la première fois == | ||
| - | - Vérifier que le déroulé du test est compréhensible, | ||
| - | - Si des pièces sont manquantes les ajouter dans le gestionnaire de fichier du wiki dans le dossier test et récupérer l' | ||
| - | - Vérifier que le lien est fait avec **toutes** les fonctionnalités touchées dans le test (Cette vérification est à faire dans la carto " | ||
| - | == Déroulement du test == | ||
| - | - Suivre **a la lettre** la procédure indiqué | ||
| - | - Si on arrive au résultat escompté ajouter le résultat en cochant la case OK, | ||
| - | - dans la cas contraire : | ||
| - | - créer un ticket projeqtor indiquant le test et le problème rencontré | ||
| - | - ajouter le résultat en décochant la case OK et en indiquant dans le commentaire le numéro du ticket projeqtor | ||
| - | |||
| - | ==== Tests fonctionnels ==== | ||
| - | |||
| - | Les tests fonctionnels on pour but de tester de manière automatique des grandes fonctionnalités du logiciel : tests de non-régression des fonctionnalités de haut-niveau (ex. : génération) en se basant sur des jeux de données validés et en comparant le résultat de l' | ||
| - | |||
| - | ==== Tests Unitaires (non remis en version WEB) ==== | ||
| - | |||
| - | Tests automatiques des grandes fonctions internes. Ces tests sont encodés dans un programme parallèle en utilisant le framework DUNIT.\\ | ||
| - | Nous utilisons ce framework de test à code source libre, pour le développement et l' | ||
| - | Le framework DUnit est disponible pour Delphi et C++. Ce framework simplifie le processus de développement de tests pour les classes et méthodes de nos applications.\\ | ||
| - | L' | ||
| - | [[http:// | ||
| - | |||
| - | [[: | ||
| - | |||
| - | |||
| - | ==== Tests Internes ==== | ||
| - | |||
| - | Le logiciel réalise des tests internes à divers moments clefs. \\ Ces tests ont pour but d' | ||
| - | |||
| - | * à la bonne utilisation du logiciel, | ||
| - | * à la conformité de sa comptabilité aux règles générales, | ||
| - | |||
| - | mais aussi à détecter des problèmes internes lors des phases initiales de saisie. Certains problèmes sont à corriger par l' | ||
| - | |||
| - | [[: | ||
| - | |||
| - | |||
| - | |||
| - | |||
| - | ===== Qui écrit et qui passe les tests ? ===== | ||
| - | |||
| - | La personne qui code le correctif n'est pas celle qui teste (on parle bien ici des tests finaux et répétitifs). \\ C'est la personne qui décrit le bug (s'il est important) qui met en place le test (et le passe une première fois). | ||
| - | |||
| - | On trouvera ci-dessous les éléments de procédures à suivre sous forme d' | ||
| - | |||
| - | ==== Bug découvert ou remonté ==== | ||
| - | |||
| - | * Le bug est décrit, par Mlle. K., si celui-ci est critique, elle met en place un test et un jeu de données afin de pouvoir tester le résultat dans ProjeQtOr sur le ticket numéro 52, il est alors affecté au responsable du pôle developpement M. G., qui le gère et le fait traiter par M. V. . | ||
| - | * A la fin du traitement M. V. pensant qu'il n'y a plus d' | ||
| - | * Celle-ci explicite dans l' | ||
| - | * Dans le cas où le test est OK elle avertit le responsable des tests M. N. afin que ce test soit intégré dans le SIGdT et qu'il puisse être réalisé quand une des unités ascendantes est modifiée | ||
| - | |||
| - | |||
| - | ==== Réalisation des tests avant livraison d'une version ==== | ||
| - | |||
| - | * Une beta Vx est générée. | ||
| - | * Le SIGdT est exécuté par le responsable des développements M. G. SIGdT vérifie la liste des unités modifiées depuis la dernière release, il en déduit la liste des unités interfaces qui doivent être re-testées et donc la liste des exigences (au sens ProjeQtOr) qui risquent de ne plus être satisfaites. | ||
| - | * Il fait parvenir la liste à M. N. en charge des tests qui les repartit entre Mlles. K., M. et lui-même. | ||
| - | * Si un test n'est pas OK un ticket de bug est émis et affecté à M. G. | ||
| - | * Si tout les tests sont OK, M. G. est avertit par M. N. qu'il peut basculer la beta Vx en release Vx, sinon il corrige et sort une Vx.y et reboucle au début de ce paragraphe. | ||
| - | |||
| - | \\ | ||
| - | |||