Difference between revisions of "SME Server:Documentation:QA:Verification/fr"
Line 154: | Line 154: | ||
Si vous vous sentez capable, veuillez suggérer les informations que nous pouvons mettre dans les notes de publication en une ou deux lignes, si vous ne pouvez pas laisser cette case vide, ou par exemple, spécifier qu'elle doit être déterminée en spécifiant '' T. B. D. ''. (A faire ? NdT) | Si vous vous sentez capable, veuillez suggérer les informations que nous pouvons mettre dans les notes de publication en une ou deux lignes, si vous ne pouvez pas laisser cette case vide, ou par exemple, spécifier qu'elle doit être déterminée en spécifiant '' T. B. D. ''. (A faire ? NdT) | ||
− | [[Category:SME Server | + | [[Category:SME Server]][[Category:Howto/fr]][[Category:Help]][[Category:Developer]] |
Revision as of 14:21, 31 March 2020
ASSURANCE QUALITÉ - Vérification
Tous les bogues ne nécessitent pas de correctifs de code, mais une grande partie d'entre eux oui. Une partie importante du processus d'assurance qualité (AQ / QA) consiste à vérifier qu'un bogue est résolu lorsque son code a été modifié. Nous faisons de notre mieux pour ne pas négliger les choses, mais cela peut arriver, une vérification appropriée est importante pour réduire le risque que de telles choses se passent. Par conséquent, nous essayons de nous en tenir à un certain flux de travail lors de la vérification. Étant donné que l'équipe de développement et les ressources sont plutôt limitées, il est assez difficile d'essayer de corriger tous les bogues soulevés, et encore moins de les vérifier. Étant donné que vous n'avez pas besoin d'être un développeur pour vérifier les correctifs qui ont été produits, ce guide est écrit pour aider tous les membres de notre communauté à nous aider dans le processus de vérification, il s'agit d'un élément essentiel de la maintenance continue du Serveur SME KOOZALI.
Déroulement général du travail
Comme mentionné précédemment, nous essayons de nous en tenir à un certain déroulé du travail lors de la vérification des bogues. En général, le processus peut être divisé selon les étapes suivantes :
- . état de la boîte de test ;
- . description du bogue ;
- . lister un nouveau paquet corrigeant le problème ;
- . vérifier quel paquet est actuellement installé ;
- . répliquer le problème en détail ;
- . installer un nouveau paquet ;
- . vérifier que le nouveau paquet a été installé ;
- . répéter les tests ci-dessus (5e ligne) ;
- . corrigé / non corrigé sur le fondement des nouveaux tests, conclusion : VÉRIFIÉ ou RÉOUVERT ;
- . détailler tout impact sur la documentation, c-à-d nouvelle base de données ou autre ;
- . bref résumé de ce que le nouveau paquet a réalisé, par exemple corrigé ceci ou cela.
Comment mettre à niveau les nouveaux paquets
Le rapport de bogue détaillera le paquet et la version exacts nécessaires. Ceux-ci sont normalement dans le dépôt de test « smeupdates-testing » et peuvent être installés par :
yum --enablerepo=smeupdates-testing <nom_du_paquet>
par exemple :
yum --enablerepo=smeupdates-testing e-smith-ldap
Comme le déplacement des paquets vers le dépôt « smeupdates-testing » est une étape manuelle , les paquets les plus récents seront dans le dépôt « smetest » et pourront être installés à partir de là si besoin. par exemple :
yum --enablerepo=smetest update e-smith-ldap
ou si vous avez besoin de plusieurs dépôts :
yum --enablerepo=smetest,smeupdates-testing,smedev update e-smith-ldap
Modèle
Le processus ci-dessus est documenté dans le champ de commentaire d'un bogue en utilisant le modèle suivant ; plus d'informations sur les étapes et les sections du modèle peuvent être trouvées ci-dessous.
VERIFICATION TEMPLATE
= ENVIRONMENT: = ORIGINAL PROBLEM: = RESOLUTION: = CURRENT VERSION INSTALLED: = TESTING: = UPDATED VERSION INSTALLED: = PROBLEM FIXED: = VERIFIED OR REOPEN: = DOCUMENTATION IMPACT: = SUGGESTED RELEASE NOTES:
COMME PAR EXEMPLE :
VERIFICATION = ENVIRONMENT: [description du système de test (version, méthodes d'installation, historique des mises à jour, etc.). Si vous avez installé un paquet non essentiel, exécutez /sbin/e-smith/audittools/newrpms et fournissez la sortie] = ORIGINAL PROBLEM: [Résumer le bogue] = RESOLUTION: [Insérer le journal des modifications pour le nouveau paquet] Par exemple : Fixé dans e-smith-base * 21 avril 2013 chris burnat <devlist@burnat.com> 5.4.0-27.sme - Fixez le chemin "." travaille en bash [SME: 7532] = CURRENT VERSION INSTALLED: [rpm -qa <package name>] =TESTING: [Reproduisez le bogue si vous le pouvez, en montrant les étapes suivies.] = UPDATED VERSION INSTALLED: [Mettre à jour vers le nouveau package, montrer les étapes suivies] et : [rpm -qa <package name>] = PROBLEM FIXED?: [Répétez les étapes effectuées sous TEST ci-dessus] = VERIFIED OR REOPEN: [Problème résolu, alors VÉRIFIÉ - non résolu, alors RÉOUVERT] Remarque : si vous n'avez pas le droit de basculer la résolution, quelqu'un le fera pour vous
= DOCUMENTATION IMPACT: [Est-ce que quelque chose nécessite une documentation, par exemple une base de données ou une nouvelle procédure ? Si oui, veuillez fournir des détails, quelqu'un les passera plus tard à l'équipe de la documentation pour action]
= SUGGESTED RELEASE NOTES: [Résumé de ce qui a été corrigé]
Environment
Étant donné que certains bogues peuvent apparaître dans plusieurs versions de nos produits (par exemple, SME Server 7.x ainsi que SME Server 8.x et maintenant SME Server 9.x), nous devons nous assurer que vous effectuez le processus de vérification en utilisant l'environnement approprié. La plupart du temps, ce serait quelque chose comme ceci :
SME Server 9.2 fully updated, no contribs installed
Problème d'origine
Cette section est utilisée pour montrer que vous pouvez reproduire le problème d'origine sur votre machine de test. Il est important que vous le fassiez aussi précisément et méthodologiquement que possible car vous devrez reproduire ces étapes après avoir mis à jour vers le(s) nouveau(x) paquet(s) pour montrer que le problème est réellement résolu. Assurez-vous d'effectuer vos tests aussi largement que nécessaire, mais d'un autre côté, essayez de garder les choses aussi claires et concises que possible. Dans le cas de demandes de nouvelles fonctionnalités (NFR - New Feature Requests) ou si une version précédente du paquet avec le bogue signalé n'est pas disponible, cette étape peut être ignorée.
Résolution
Cette section est utilisée pour décrire brièvement les étapes à suivre pour effectuer la mise à niveau vers la version corrigée, généralement ce sera quelque chose comme ceci :
Installez paquet1 et paquet2 à partir de smeupdates-testing et/ou smetest ou le correctif xyz est à appliquer, etc.
Après cela, il est temps de mettre à niveau le ou les nouveau(x) paquet(s).
Version courante installée
Lorsque le bogue est signalé et diagnostiqué normalement, le paquet qui doit être corrigé, ainsi que la version du paquet peuvent être documentés, mais le nom du paquet et la version sur lesquels le problème a été résolu doivent être signalés par le développeur, ce sera quelque chose comme ci-dessous :
Nom du paquet corrigé
* Jeu 25 novembre 2010 John Doe <jdoe@fqdn.org> x.y.z-r.sme - Brève description du correctif [SME: bugnumber]
La version prévue ici est la version du paquet avec le bogue présent, généralement la sortie de la commande rpm -q fera l'affaire, donc la plupart du temps cela ressemblera à ceci :
[root@smetest ~]# rpm -q e-smith-base e-smith-base-5.2.0-28.el5.sme [root@smetest ~]#
Tests
Décrire en détail le problème existant corrigé par le nouveau paquet.
Version mise à jour installée
Cette section est analogue à la version actuelle installée et est destinée à montrer que le(s) paquet(s) mis à jour sont en fait installés avant de vérifier que le bogue a été corrigé, généralement un rpm -q pour les paquets mis à jour pourrait le faire.
Problème corrigé
C'est le cœur du processus de vérification car c'est ici que nous montrons que le problème est réellement résolu. Vous pouvez utiliser les mêmes étapes que celles utilisées dans la section Problème d'origine. Assurez-vous de vérifier que non seulement le problème est résolu, mais assurez-vous également qu'aucun message d'erreur ne se trouve dans les fichiers journaux ou sur la console lors de la saisie des commentaires. Si des erreurs sont présentes, veuillez les signaler au rapport de bogue si cela affecte le correctif, ou ouvrez un nouveau bogue lorsqu'un nouveau problème est découvert. Assurez-vous également de tester les fonctionnalités normales en relation avec les modifications fonctionnent toujours correctement.
Vérifié ou Ré-ouvert
C'est la section où nous concluons sur le processus de vérification. Si le paquet corrigé fonctionne et qu'il n'y a pas d'effets secondaires négatifs, nous pouvons conclure que le paquet est VÉRIFIÉ, sinon il pourrait être RÉ-OUVERT. Si vous avez trouvé d'autres bogues dans le processus, vous pouvez également les indiquer ici (brièvement), mais veuillez garder à l'esprit que les nouveaux problèmes doivent être signalés dans un nouveau rapport de bogue. Lorsque vous ROUVREZ le bogue, veuillez le justifier brièvement.
Impact sur la documentation
Par exemple : une variable DB a-t-elle été créée/supprimée ?
Notes de version suggérées
Si vous vous sentez capable, veuillez suggérer les informations que nous pouvons mettre dans les notes de publication en une ou deux lignes, si vous ne pouvez pas laisser cette case vide, ou par exemple, spécifier qu'elle doit être déterminée en spécifiant T. B. D. . (A faire ? NdT)