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 |