SME Server:Documentation:QA:Verification/fr

Languages:

English  • français

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.

	Attention :
	KOOZALI SME 10. Pour installer un serveur de test, voir cette page.

1. Installer et configurer un serveur à partir de l'iso.

2. Les paquets smeserver-yum, e-smith-base et smeserver-support doivent d'abord être mis à jour à partir du dépôt smeupdates-testing :

yum update smeserver-yum e-smith-base smeserver-support --enablerepo=smeupdates-testing

3. Après redémarrage, appliquer totalement :

yum update

Ensuite faire un « snapshot », une copie instantanée de votre machine virtuelle (MV), cf. cette fonction dans le menu de PROXMOX. Un « snapshot » conserve l'état et les données d'une machine virtuelle au moment de sa création. Lorsque vous créez un snapshot d'une machine virtuelle, cette machine virtuelle n'est pas affectée et seule une image de cette machine dans un état donné est copiée et stockée. Les snapshots sont utiles lorsque vous devez retourner à plusieurs reprises au même état mais que vous ne souhaitez pas créer plusieurs machines virtuelles. C'est aussi très utile en cas de plantage de la MV.

En cas de plantage de la MV en cours de réalisation d'un snapshot, se placer dans une ligne de commande de PVE et faire :

qm unlock ID      # où ID est le numéro de la VM

Après un test, restaurer la MV dans l'état d'installation.

Et repartez pour un nouveau test.

Une mise à jour de tinydns et/ou dnscache cassera les DNS. Vous devrez démarrer manuellement ces services après le redémarrage et ensuite les mettre à jour.

La vérification d'un paquet doit être faite avec :

yum update —enablerepo=smeupdates-testing nom_du_paquet

Auparavant, vous devez utiliser la même commande pour les paquets smeserver-yum, e-smith-base et smeserver-support pour s'assurer d'avoir les derniers scripts en cours.

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 :

1. . état de la boîte de test ;
2. . description du bogue ;
3. . lister un nouveau paquet corrigeant le problème ;
4. . vérifier quel paquet est actuellement installé ;
5. . répliquer le problème en détail ;
6. . installer un nouveau paquet ;
7. . vérifier que le nouveau paquet a été installé ;
8. . répéter les tests ci-dessus (5e ligne) ;
9. . corrigé / non corrigé sur le fondement des nouveaux tests, conclusion : VÉRIFIÉ ou RÉOUVERT ;
10. . détailler tout impact sur la documentation, c-à-d nouvelle base de données ou autre ;
11. . bref résumé de ce que le nouveau paquet a réalisé, par exemple corrigé ceci ou cela.

La liste des paquets nécessitant un test de vérification se trouve dans : Verification_Queue

Comment mettre à niveau les nouveaux paquets

	Note :
	bien sûr, nous faisons du bon code mais nous pouvons ralentir votre système, il est donc fortement conseillé de faire la vérification sur un serveur SME virtuel.

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.

	Remarque :
	n'oubliez pas de définir également le champ d'état, au bas du champ de commentaire, à la valeur appropriée correspondant à votre conclusion.

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)

Vérification succincte

À n'utiliser que lorsque les circonstances dictent l'urgence d'effectuer plusieurs vérifications en peu de temps.

= CURRENT VERSION INSTALLED:
[rpm -qa <package name>]

Si c'est un bogue en cours, montrez la solution si vous le pouvez, en montrant les étapes suivies, sinon montrez simplement qu'il fonctionne, l'emplacement, tous les modèles, paramètres de configuration, paramètres de base de données, etc. qui seront ou peuvent être modifiés.

= UPDATED VERSION INSTALLED:

Mettre à jour vers un nouveau paquet, afficher les étapes suivies.

# yum updat/install e-smith-base --enablerepo=smeupdates=testing ou smetest

Vérifier les dernières versions, cela évolue rapidement avec les changements. Redémarrer, reconfigurer si nécessaire, bonne idée au cas où, et :

[rpm -qa <package name>]

Montrer son fonctionnement si possible et/ou aucune erreur évidente dans les logs, etc.

= VERIFIED OR REOPEN:

Problème résolu, alors « VERIFIED » - non résolu, alors « REOPEN ». Remarque: si vous n'avez pas le droit de changer le statut du bogue, quelqu'un le fera pour vous.

= DOCUMENTATION IMPACT:

Quelque chose a-t-il besoin d'être documenté, par exemple une base de données ou une nouvelle procédure ? Si oui, veuillez fournir des détails, quelqu'un l'affectera plus tard à l'équipe de documentation pour action.