Documentation PostgreSQL 7.4.29 | ||||
---|---|---|---|---|
Pr�c�dent | Arri�re rapide | Avance rapide | Suivant |
Les tests de r�gression composent un ensemble exhaustif de tests de l'impl�mentation du SQL au sein de PostgreSQL. Ils permettent de tester les op�rations SQL standard ainsi que les fonctionnalit�s �tendues de PostgreSQL. Depuis PostgreSQL 6.1, les tests de r�gression sont actualis�s pour chaque version officielle.
Les tests de r�gression peuvent �tre lanc�s sur un serveur d�j� install� et fonctionnel ou en utilisant une installation temporaire � l'int�rieur du r�pertoire de construction. De plus, ils peuvent �tre lanc�s en mode <<�parall�le�>> ou en mode <<�s�quentiel�>>. Le mode s�quentiel lance les scripts de test en s�rie, tandis que le mode parall�le lance plusieurs processus serveurs pour parall�liser l'ex�cution des groupes de tests. Les tests parall�les permettent de s'assurer du bon fonctionnement des communications interprocessus et du verrouillage. Pour des raisons historiques, les tests s�quentiels sont habituellement lanc�s sur une installation existante et la m�thode parall�le pr�f�rentiellement sur une installation temporaire, mais il n'y a aucune raison technique � cela.
Pour lancer les tests de r�gression apr�s la construction mais avant l'installation, il suffit de saisir
gmake check
dans le r�pertoire de premier niveau (on peut aussi se placer dans le r�pertoire src/test/regress et y lancer la commande). En premier lieu seront construits diff�rents fichiers auxiliaires, tels des exemples de fonctions de d�clencheurs utilisateur, puis le script de pilotage des tests sera ex�cut�. Au final, la sortie devrait ressembler � quelque chose comme
====================== All 93 tests passed. ======================
ou une note indiquant l'�chec des tests. Voir Section 26.2 ci-dessous pour plus d'informations.
Comme cette m�thode de tests fonctionne sur un serveur temporaire, le superutilisateur, root, ne pourra les lancer. Si la construction a �t� initi�e par un uilisateur root, il suffit de rendre le r�pertoire contenant les tests de r�gression modifiable par un autre utilisateur. Les tests seront alors lanc�s par cet utilisateur. Par exemple
root# chmod -R a+w src/test/regress root# chmod -R a+w contrib/spi root# su - joeuser joeuser$ cd r�pertoire_construction_premier_niveau joeuser$ gmake check
(La seule <<�faille de s�curit�>> potentielle � ce niveau est une modification insidieuse des r�sultats des tests de r�gression par d'autres utilisateurs. Le bon sens guidera la gestion des droits des utilisateurs.)
L'autre possibilit� consiste � lancer les tests apr�s l'installation.
Les tests de r�gression parall�les lancent plusieurs processus par utilisateur. Actuellement, le nombre maximum est de vingt scripts de tests en parall�le, soit 60 processus : il y a un processus serveur, un psql et habituellement un processus parent pour le psql de chaque script de tests. Si le syst�me impose une limite par utilisateur sur le nombre de processus, il faudra s'assurer que cette limite est d'au moins 75, sans quoi pourraient appara�tre des �checs apparemment al�atoires. Si cette limite ne peut �tre modifi�e, le degr� de parall�lisme pourra �tre r�duit en initialisant le param�tre MAX_CONNECTIONS. Par exemple,
gmake MAX_CONNECTIONS=10 check
ne lancera pas plus de dix tests simultan�s.
Sur certains syst�mes, le shell compatible Bourne install� par d�faut (/bin/sh) a du mal � g�rer de nombreux processus fils en parall�le. Cela peut engendrer des blocages ou des �checs lors des tests en parall�le. Dans ce cas, il suffira de sp�cifier en ligne de commande un shell compatible Bourne diff�rent. On peut, par exemple, �crire :
gmake SHELL=/bin/ksh check
Si aucun shell satisfaisant n'est disponible, le probl�me sera contourn� par la diminution du nombre de connexions comme indiqu� ci-dessus.
Le lancement des tests apr�s installation (voir Chapitre 14)se fait en trois �tapes, l'initialisation d'un espace de donn�es, le lancement du serveur comme expliqu� dans Chapitre 16, et le lancement des tests :
gmake installcheck
Les tests tenteront de contacter le serveur sur l'h�te local avec le num�ro de port par d�faut. Pour modifier le comportement par d�faut, il suffira de renseigner les variables d'environnement PGHOST et PGPORT.
Pr�c�dent | Sommaire | Suivant |
Internes | Niveau sup�rieur | �valuation des tests |