33.2. Оценка результатов тестирования #
Некоторые правильно установленные и полностью функциональные PostgreSQL инсталляции могут «давать сбой» при прохождении некоторых регрессионных тестов из-за особенностей, присущих той или иной платформе, таких как различное представление чисел с плавающей точкой и формулировкой сообщений. В настоящее время результаты тестов оцениваются простым diff сравнением с выводом, сделанным в эталонной системе, поэтому результаты чувствительны к небольшим отличиям между системами. Когда тест завершается со «сбоем», всегда исследуйте разницу между ожидаемым и полученным результатом; возможно, вы обнаружите, что разница не столь уж существенна. Тем не менее мы стремимся поддерживать эталонные файлы на всех поддерживаемых платформах, чтобы можно было ожидать прохождения всех тестов.
Актуальные итоговые результаты регрессионного тестирования хранятся в каталоге src/test/regress/results. Тестовый скрипт использует команду diff, чтобы сравнить каждый итоговый файл с ожидаемыми результатами, которые хранятся в каталоге src/test/regress/expected. Все различия сохраняются в src/test/regress/regression.diffs для последующей проверки. (Если проводился тест не из основного пакета, то его результаты появятся в соответствующем подкаталоге, а не в src/test/regress.)
Если вам не нравятся используемые по умолчанию аргументы diff, установите переменную среды PG_REGRESS_DIFF_OPTS, например PG_REGRESS_DIFF_OPTS='-c'. (Или, если хотите, запустите diff самостоятельно.)
Если по какой-то причине какая-то конкретная платформа генерирует «сбой» для отдельного теста, но изучение его результата убеждает вас, что результат правильный, вы можете добавить новый файл сравнения, чтобы замаскировать отчёт об ошибке для последующего прохождения теста. За подробностями обратитесь к Разделу 33.3.
33.2.1. Различия в сообщениях об ошибке #
Некоторые регрессионные тесты подставляют заведомо неверные входные значения. Сообщения об ошибке могут выдаваться как PostgreSQL, так и самой операционной системой. В последнем случае форма сообщений может отличаться в зависимости от платформы, но отражают они одну и ту же информацию. Вот эта разница в сообщениях и приводит к «сбоям» регрессионного теста, которые можно устранить при проверке.
33.2.2. Разница локалей #
Если вы проводите тестирование на сервере, который был установлен с локалью, имеющей порядок сопоставления, отличный от С, вы можете столкнуться с различиями в порядке сортировки и, как следствие, с последующими сбоями. Пакет регрессионных тестов решает эту проблему путём наличия альтернативных файлов результата, которые способны справиться с большим количеством локалей.
Если вы используете метод тестирования на временной инсталляции, то чтобы запустить тестирование на другой локали, используйте подходящую переменную среды, относящуюся к локали, в командной строке make, например:
make check LANG=de_DE.utf8
(Драйвер регрессионного теста обнуляет LC_ALL, поэтому выбор локали посредством данной переменной не работает.) Чтобы не использовать локаль, либо обнулите все переменные среды, относящиеся к локали, либо установите их в C) или используйте следующую специальную команду:
make check NO_LOCALE=1
Когда тест проходит на существующей инсталляции, установки локали определяются этой инсталляцией. Чтобы это изменить, инициализируйте кластер базы данных с иной локалью, передав соответствующие параметры initdb.
В целом, рекомендуется по возможности проводить регрессионные тесты при таких установках локали, которые будут использованы в работе, тогда в результате тестирования будут проверены актуальные участки кода, относящиеся к локали и кодировке. В зависимости от окружения операционной системы, вы можете столкнуться со сбоями, но вы хотя бы будете знать, какого поведения локали можно ожидать при работе с реальными приложениями.
33.2.3. Разница в дате и времени #
Большая часть результатов проверки даты и времени зависит от часового пояса окружения. Эталонные файлы созданы для пояса PST8PDT (Беркли, Калифорния), поэтому если проводить тесты не с этим часовым поясом, проявятся мнимые ошибки. Драйвер регрессионного теста задаёт переменную среды PGTZ как PST8PDT, что позволяет получить корректный результат.
33.2.4. Разница в числах с плавающей точкой #
Некоторые тесты применяют 64-битное вычисление чисел с плавающей точкой (double precision) из столбцов таблицы. Наблюдаются различия в результатах при использовании математических функций для столбцов double precision. Тесты float8 и geometry особенно чувствительны к небольшим различиям между платформами и даже режимами оптимизации компилятора. Чтобы понять реальную значимость этих различий, нужно сравнить их глазами, поскольку обычно они располагаются с десятого разряда справа от десятичной точки.
Некоторые системы показывают минус ноль как -0, тогда как другие показывают просто 0.
Некоторые системы сигнализируют об ошибках в pow() и exp() не так, как ожидает текущий код PostgreSQL.
33.2.5. Разница в сортировке строк #
Иногда наблюдаются различия в том, что одни и те же строки выводятся в ином порядке, нежели в контрольном файле. В большинстве случаев это не является, строго говоря, ошибкой. Основная часть скриптов регрессионных тестов не столь педантична, чтобы использовать ORDER BY для каждого SELECT, и поэтому в результате порядок строк не гарантирован согласно спецификации SQL. На практике мы видим, как одинаковые запросы, выполняемые для одних и тех же данных на одном и том же программном обеспечении, выдают результаты в одинаковом порядке для всех платформ, в связи с чем отсутствие ORDER BY не является проблемой. Однако некоторые запросы выявляют межплатформенные различия в сортировке. Когда тестирование идет на уже установленном сервере, различия в сортировке могут быть следствием того, что локаль установлена в отличное от С значение, или некоторые параметры заданы не по умолчанию, такие как work_mem или стоимостные параметры планировщика.
Поэтому, если вы видите различия в сортировке строк, не стоит волноваться, если только запрос не использует ORDER BY. Тем не менее сообщайте нам о таких случаях, чтобы мы могли добавить ORDER BY в конкретный запрос, чтобы исключить возможность ошибки в будущих релизах.
Вы можете задать вопрос, почему мы явно не добавили ORDER BY во все запросы регрессионных тестов, чтобы избавиться от таких ошибок раз и навсегда. Причина в том, что это снизит полезность регрессионных тестов, поскольку они будут иметь тенденцию к проверке планов запросов использующих сортировку, за счёт исключения запросов без сортировки.
33.2.6. Недостаточная глубина стека #
Если ошибки теста приводят к поломке сервера при выполнении команды select infinite_recurse(), это означает, что предел платформы для размера стека меньше, чем показывает параметр max_stack_depth. Проблема может быть решена запуском сервера с большим размером стека (рекомендованное значение max_stack_depth по умолчанию - 4 Мб). Если вы не можете этого сделать, в качестве альтернативы уменьшите значение max_stack_depth.
На платформах, поддерживающих функцию getrlimit(), сервер должен автоматически выбирать значение переменной max_stack_depth; поэтому, если вы не переписывали это значение вручную, сбой такого типа — просто дефект, который нужно зарегистрировать.
33.2.7. Тест «случайных значений» #
Тестовый скрипт random подразумевает получение случайных значений. В очень редких случаях это приводит к сбоям в регрессионном тестировании. Выполнение
diff results/random.out expected/random.out
должно выводить одну или несколько строк различий. Нет причин для беспокойства, до тех пор пока сбои в этом тесте не повторяются постоянно.
33.2.8. Параметры конфигурации #
Когда тестирование проходит на существующей инсталляции, некоторые нестандартные значения параметров могут привести к сбоям в тесте. Например, изменение таких параметров конфигурации, как enable_seqscan или enable_indexscan могут привести к такому изменению системы, которое сможет воздействовать на результаты тестов, использующих EXPLAIN.