| Documentation PostgreSQL 8.0.2 | ||||
|---|---|---|---|---|
| Précédent | Arrière rapide | Chapitre 26. Tests de régression | Avance rapide | Suivant |
Quelques installations de PostgreSQL proprement installées et totalement fonctionnelles peuvent << échouer >> sur certains des tests de régression à cause de certains points spécifiques à la plateforme comme une représentation de nombres à virgules flottantes ou un support des fuseaux horaires. Les tests sont actuellement évalués en utilisant une simple comparaison diff avec les sorties générées sur un système de référence, donc les résultats sont sensibles aux petites différences système. Quand un test est rapporté comme << échoué >>, toujours examiner les différences entre les résultats attendus et obtenus ; vous pourriez très bien trouver que les différences ne sont pas significatives. Néanmoins, nous nous battons toujours pour maintenir des fichiers de références précis et à jour pour toutes les plateformes supportés de façon à ce que tous les tests puissent réussir.
Les sorties actuelles des tests de régression sont dans les fichiers du répertoire src/test/regress/results. Le script de test utilise diff pour comparer chaque fichier de sortie avec les sorties de référence stockées dans le répertoire src/test/regress/expected. Toutes les différences sont conservées pour que vous puissiez les regarder dans src/test/regress/regression.diffs. (Ou vous pouvez lancer diff vous-même, si vous préférez.)
Certains des tests de régression impliquent des valeurs en entrée intentionnellement invalides. Les messages d'erreur peuvent provenir soit du code de PostgreSQL soit des routines système de la plateforme hôte. Dans ce dernier cas, les messages pourraient varier entre plateformes mais devraient toujours refléter des informations similaires. Ces différences dans les messages résulteront dans un test de régression << échoué >> qui pourrait être validé après vérification.
Si vous lancez des tests sur un serveur déjà installé mais initialisé avec une locale autre que C, alors il pourrait y avoir des différences dans les ordres de tris. La suite de tests de régression est initialisée pour gérer ce problème en fournissant des fichiers de résultats alternatifs qui ensemble gèrent un grand nombre de locales. Par exemple, pour le test char, le fichier char.out attendu gère les locales C et POSIX, et le fichier char_1.out gère beaucoup d'autres locales. Le pilote des tests de régression choisira automatiquement le meilleur fichier lors de la vérification et pour la calcul des différences d'échecs. (Ceci signifie que les tests de régression ne peuvent pas détecter si les résultats sont appropriés pour la locale configurée. Ils vont simplement récupérer le fichier résultat qui fonctionne le mieux.)
Si, pour une quelconque raison, les fichiers attendus ne couvrent pas certaines locales, vous pouvez ajouter un nouveau fichier. Le schéma de nommage est nom_test_chiffre.out. Le chiffre n'a en fait pas de signification. Rappelez-vous que le pilote des tests de régression considèrera tous les fichiers comme étant des résultats de tests valides. Si les résultats de tests sont spécifiques à une plateforme, la technique décrite dans Section 26.3 devrait être utilisée à la place.
Quelques requêtes des tests d'horologie échoueront si vous lancez les tests un jour de changement de heure ou le lendemain de ce jour. Ces requêtes s'attendent à ce que les intervalles entre minuit hier, minuit aujourd'hui et minuit demain soient exactement 24 heures -- ce qui est faux lorsqu'un changement d'heure intervient.
Note : Comme les règles de changement d'heure des USA sont utilisées, ce problème arrive toujours le premier dimanche d'avril, le dernier dimanche d'octobre et les lundis suivants quelque soit le changement d'heure effectif où vous vivez. Notez aussi que le problème apparaît ou disparaît à minuit, UTC-7 ou UTC-8, pas à un minuit chez vous. Donc, l'échec pourrait arriver plus tard le dimanche ou persister jusqu'au mardi suivant l'endroit où vous vivez.
La plupart des résultats date/heure sont dépendants de l'environnement de zone horaire. Les fichiers de référence sont générés pour la zone horaire PST8PDT (Berkeley, Californie), et il y aura des échecs apparents si les tests ne sont pas lancés avec ce paramètrage de fuseau horaire. Le pilote des tests de régression initialise la variable d'environnement PGTZ à PST8PDT ce qui nous assure normalement de bons résultats.
Quelques tests impliquent des calculs sur des nombres flottants à 64 bits (double precision) à partir des colonnes des tables. Les différences dans les résultats impliquant les fonctions mathématiques de colonnes double precision ont été observées. Les tests de float8 et geometry sont particulièrement sensibles aux petites différences sur les différentes plateformes, voire même avec différentes options de compilation. La comparaison d'un œil humain est nécessaire pour déterminer la vraie raison de ces différences qui sont habituellement sur les dix places à droite du point décimal.
Certains systèmes affichent moins zéro comme -0 alors que d'autres affichent seulement 0.
Certains systèmes signalent des erreurs avec pow() et
exp() différemment suivant le mécanisme attendu du
code de PostgreSQL.
Vous pourriez voir des différences dans lesquelles les mêmes lignes sont affichées dans un ordre différent de celui qui apparaît dans le fichier de référence. Dans la plupart des cas, ce n'est pas à strictement parlé un bogue. La plupart des scripts de tests de régression ne sont pas assez stricts pour utiliser un ORDER BY sur chaque SELECT, et du coup l'ordre des lignes pourrait ne pas être correctement défini suivant la spécification SQL. En pratique, comme nous sommes avec les mêmes requêtes sur les mêmes données avec le même logiciel, nous obtenons habituellement le même résultat sur toutes les plateformes et le manque d'ORDER BY n'est pas un problème. Quelques requêtes affichent des différences d'ordre entre plateformes. (Les différentes d'ordre peuvent aussi être déclenchées par une locale autre que C.)
Du coup, si vous voyez une différence dans l'ordre, vous n'avez pas à vous inquiéter sauf si la requête possède un ORDER BY que votre résultat ne respecte pas. Mais rapportez tout de même ce problème que nous ajoutions un ORDER BY à cette requête pour éliminer les faux << échecs >> dans les versions suivantes.
Vous pourriez vous demander pourquoi nous n'ordonnons pas toutes les requêtes des tests de régression explicitement pour supprimer ce problème une fois pour toutes. La raison est que cela rendrait les tests de régression moins utiles car ils tendraient à exercer des types de plans de requêtes produisant des résultats ordonnés à l'exclusion de celles qui ne le font pas.
Le script de tests random a pour but de produire des résultats aléatoires. Dans de rares cas, ceci fait que random échoue aux tests de régresson. Saisir
diff results/random.out expected/random.out
devrait seulement produire une ou plusieurs lignes différentes. Vous ne devez pas vous en faire sauf si les tests random échouent de façon répété.
| Précédent | Sommaire | Suivant |
| Tests de régression | Niveau supérieur | Fichiers de comparaison spécifiques à la plateforme |