31.1. Выполнение тестов #
Регрессионное тестирование можно выполнять как на уже установленном и работающем сервере, так и используя временную инсталляцию внутри дерева сборки. Более того, существуют «параллельный» и «последовательный» режимы тестирования. Последовательный метод выполняет каждый сценарий теста отдельно, тогда как параллельный метод запускает несколько процессов на сервере, чтобы выполнить определённый набор тестов параллельно. Параллельное тестирование позволяет с уверенностью утверждать, что межпроцессное взаимодействие и блокировки работают корректно. Некоторые тесты могут выполняться последовательно даже в «параллельном» режиме, если это требуется для выполнения тестирования.
31.1.1. Запуск тестов на временной инсталляции #
Чтобы запустить параллельное регрессионное тестирование после сборки, но до инсталляции, наберите:
make check
в каталоге верхнего уровня. (Или перейдите в src/test/regress
и выполните команду там.) Для тестов, выполняющихся в параллельном режиме, добавляется префикс «+», для тестов в последовательном режиме используется префикс «-». По завершении процесса вы должны увидеть нечто вроде:
# All 213 tests passed.
или список тестов, не пройденных успешно. Прочитайте Раздел 31.2, прежде чем делать вывод о серьёзности выявленных «проблем».
Поскольку данный метод тестирования выполняется на временном сервере, он не будет работать, если вы выполняете сборку под пользователем root, сервер просто не запустится из под root. Рекомендуется не делать сборку под пользователем root, если только вы не собираетесь проводить тестирование после завершения инсталляции.
Если вы сконфигурировали PostgreSQL для инсталляции в месте, где уже установлена предыдущая версия PostgreSQL, и вы выполняете make check
до инсталляции новой версии, вы можете столкнуться с тем, что тестирование завершится со сбоем, поскольку новая программа будет пытаться использовать уже установленные общие библиотеки. (Типичные симптомы - жалобы на неопределённые символы.) Если вы хотите провести тестирование до перезаписи старой инсталляции, вам необходимо проводить построение с configure --disable-rpath
. Однако этот вариант не рекомендуется для окончательной инсталляции.
Параллельное регрессионное тестирование запускает довольно много процессов под вашим именем пользователя. В настоящее время возможный максимум параллельной обработки составляет двадцать параллельных тестовых сценариев, а это означает сорок процессов: это и серверный процесс, и psql процесс для каждого тестового сценария. Поэтому если ваша система устанавливает ограничения на количество процессов для каждого пользователя, имеет смысл уточнить, что ваш лимит составляет не меньше пятидесяти процессов или около того. В противном случае вы столкнетесь с кажущимися случайными сбоями в параллельном тестировании. Если же вы не имеете права увеличить свой лимит процессов, вы можете снизить степень распараллеливания установкой параметра MAX_CONNECTIONS
. Например:
make MAX_CONNECTIONS=10 check
выполняет не больше десяти тестов параллельно.
31.1.2. Запуск тестов для существующей инсталляции #
Чтобы запустить тестирование после инсталляции (см. Главу 17), инициализируйте каталог данных и запустите сервер, как показано в Главе 18, потом введите:
make installcheck
или для параллельного тестирования:
make installcheck-parallel
Тестовые сценарии будут соединяться с сервером на локальном компьютере с номером порта по умолчанию, если иное не задано переменными среды PGHOST
и PGPORT
. Тестирование будет проведено в базе данных regression
; любая существующая база с таким именем будет удалена.
Также тесты будут создавать для временного пользования объекты, общие для кластера, такие как роли, табличные пространства и подписки. Имена этих объектов будут начинаться с regress_
. Остерегайтесь использования режима installcheck
там, где такие имена могут иметь существующие глобальные объекты.
31.1.3. Дополнительные пакеты тестов #
Команды make check
и make installcheck
запускают только «основные» регрессионные тесты, которые проверяют встроенную функциональность сервера PostgreSQL. Исходный дистрибутив содержит множество других пакетов тестов, большая часть которых имеет дело с дополнительной функциональностью, такой, как, например, дополнительные процедурные языки.
Чтобы запустить пакет тестов (включая основные) применительно к модулям, выбранным для построения, наберите одну из этих команд в каталоге верхнего уровня дерева сборки:
make check-world make installcheck-world
Эти команды запускают тестирование, используя временный или уже установленный сервер, в соответствии с данным выше описанием для команд make check
и make installcheck
. Остальные детали соответствуют ранее изложенным объяснениям для каждого метода. Необходимо иметь в виду, что команда make check-world
создаёт экземпляр кластера (временный каталог данных) для каждого тестировочного модуля, а это требует гораздо больше времени и дискового пространства, нежели команда make installcheck-world
.
На современном компьютере с множеством процессорных ядер и операционной системой без жёстких ограничений тестирование можно многократно ускорить за счёт распараллеливания. Рецепт, которым на практике пользуются большинство разработчиков для ускоренного выполнения всех тестов, выглядит примерно так:
make check-world -j8 >/dev/null
Значение для -j
обычно ограничивается количеством ядер или может быть немного больше. Подавление вывода в stdout избавляет от большого объёма сообщений, не представляющих интереса, когда нужно просто убедиться в успешности проверки. (В случае ошибки выводимые в stderr сообщения обычно дают достаточно информации для диагностики проблемы.)
В качестве альтернативного пути можно запустить индивидуальный пакет тестов, набрав make check
или make installcheck
в подходящем подкаталоге дерева сборки. Имейте в виду, что make installcheck
предполагает, что вы уже установили соответствующие модули, а не только основной сервер.
Дополнительные тесты, которые можно активизировать таким способом:
Регрессионные тесты для дополнительных процедурных языков. Эти тесты расположены в каталоге
src/pl
.Регрессионные тесты для модулей
contrib
, расположенные в каталогеcontrib
. Не для всех модулей изcontrib
существуют тесты.Регрессионные тесты для интерфейсных библиотек, расположенные в
src/interfaces/libpq/test
иsrc/interfaces/ecpg/test
.Тесты для проверки встроенных в ядро методов проверки подлинности, расположенные в
src/test/authentication
. (Ниже описываются дополнительные тесты, связанные с проверкой подлинности.)Тесты для нагрузочного тестирования параллельных сеансов, расположенные в
src/test/isolation
.Тесты для проверки физической репликации и восстановления после сбоев, расположенные в
src/test/recovery
.Тесты для проверки логической репликации, расположенные в
src/test/subscription
.Тесты клиентских программ, расположенные в
src/bin
.
При использовании режима installcheck
эти тесты будут создавать и удалять базы данных с именами, включающими слово regression
, например pl_regression
или contrib_regression
. Остерегайтесь использования этого режима там, где имеются базы с такими именами, не предназначенные для тестирования.
Некоторые из этих дополнительных пакет тестов используют инфраструктуру TAP, описанную в Разделе 31.4. TAP-тесты выполняются, только когда PostgreSQL конфигурируется с ключом --enable-tap-tests
. Этот ключ рекомендуется для разработки, но если подходящей инсталляции Perl нет, его можно опустить.
Некоторые пакеты не запускаются по умолчанию — одни потому, что выполнять их в многопользовательской системе небезопасно, другие потому, что им требуется специальное программное обеспечение, а некоторые из-за своей ресурсоёмкости. Эти пакеты тестов можно включить дополнительно, присвоив переменной PG_TEST_EXTRA
(это может быть переменная окружения или скрипта make
) строку с их списком через пробел, например:
make check-world PG_TEST_EXTRA='kerberos ldap ssl load_balance libpq_encryption'
В настоящее время поддерживаются следующие значения:
kerberos
Запускает пакет тестов в подкаталоге
src/test/kerberos
. Эти тесты требуют наличия инсталляции MIT Kerberos и открывают сокеты TCP/IP для приёма соединений.ldap
Запускает пакет тестов в подкаталоге
src/test/ldap
. Эти тесты требуют наличия инсталляции OpenLDAP и открывают сокеты TCP/IP для приёма соединений.ssl
Запускает пакет тестов в подкаталоге
src/test/ssl
. Эти тесты открывают сокеты TCP/IP для приёма соединений.load_balance
Запускает тест
src/interfaces/libpq/t/004_load_balance_dns.pl
. Этот тест требует наличия соответствующих записей в системном файлеhosts
и открывает сокеты TCP/IP для приёма соединений.libpq_encryption
Запускает тест
src/interfaces/libpq/t/005_negotiate_encryption.pl
. Этот тест открывает сокеты TCP/IP для приёма соединений. Если переменная окруженияPG_TEST_EXTRA
также содержитkerberos
, запускаются дополнительные тесты, требующие наличия инсталляции MIT Kerberos.wal_consistency_checking
Включает проверку
wal_consistency_checking=all
при выполнении определённых тестов в подкаталогеsrc/test/recovery
. По умолчанию эта проверка не производится, так как она создаёт значительную нагрузку.xid_wraparound
Запускает пакет тестов в подкаталоге
src/test/modules/xid_wraparound
. По умолчанию отключён из-за своей ресурсоёмкости.
Тесты функциональности, которая не поддерживается в текущей конфигурации сборки, не запускаются, даже если они указаны в PG_TEST_EXTRA
.
Кроме того, в каталоге src/test/modules
есть тесты, которые будут запускаться в режиме make check-world
, но не в make installcheck-world
. Это объясняется тем, что они имеют побочные эффекты или устанавливают расширения, неподходящие для производственной среды. По желанию вы можете выполнить make install
или make installcheck
в одном из его подкаталогов, но делать это с сервером, не предназначенным для тестирования, не рекомендуется.
31.1.4. Локаль и кодировка #
По умолчанию, тесты, работающие на временной инсталляции, используют локаль, определённую в текущей среде и кодировку базы данных, заданную при выполнении initdb
. Для тестирования различных локалей может оказаться полезным установить подходящие переменные среды, например:
make check LANG=C make check LC_COLLATE=en_US.utf8 LC_CTYPE=ru_RU.utf8
Поддержка переменной LC_ALL
в этом случае не реализована; все остальные переменные среды, относящиеся к локали, работают.
При тестировании на существующей инсталляции, локаль определяется имеющимся кластером базы данных и не может быть изменена для выполнения теста.
Вы можете задать кодировку базы данных в переменной ENCODING
, например:
make check LANG=C ENCODING=EUC_JP
Установка кодировки базы данных таким образом имеет смысл только для локали C; в противном случае кодировка определяется автоматически из локали, и установка кодировки, не соответствующей локали, приведёт к ошибке.
Кодировка базы данных может быть установлена как для тестирования на временной, так и на существующей инсталляции, хотя в последнем случае она должна быть совместимой с локалью этой инсталляции.
31.1.5. Пользовательские параметры сервера #
Существует несколько вариантов использования пользовательских параметров сервера при запуске пакета тестов. Такие параметры полезно задать для изменения детализации сообщений в журнале, изменения ограничений ресурсов или включения дополнительных проверок во время выполнения, например debug_discard_caches. Однако обратите внимание, что не все тесты могут проходить без ошибок с произвольными настройками.
Разным командам initdb
, выполняемым во время настройки теста, могут передаваться дополнительные параметры через переменную окружения PG_TEST_INITDB_EXTRA_OPTS
. Например, чтобы запустить тест с включёнными контрольными суммами, нестандартным размером сегментов WAL и заданным параметром work_mem
, воспользуйтесь следующей командой:
make check PG_TEST_INITDB_EXTRA_OPTS='-k --wal-segsize=4 -c work_mem=50MB'
Для основных регрессионных тестов и прочих тестов, запускаемых pg_regress
, пользовательские параметры сервера, связанные со временем выполнения, можно также задать в переменной окружения PGOPTIONS
(если это возможно), например:
make check PGOPTIONS="-c debug_parallel_query=regress -c work_mem=50MB"
(В этом случае используется функциональность libpq; за подробностями обратитесь к options.)
Когда тесты проводятся с временной инсталляцией, пользовательские параметры также можно задать в предварительно написанном postgresql.conf
:
echo 'log_checkpoints = on' > test_postgresql.conf echo 'work_mem = 50MB' >> test_postgresql.conf make check EXTRA_REGRESS_OPTS="--temp-config=test_postgresql.conf"
31.1.6. Специальные тесты #
Пакет основных регрессионных тестов содержит несколько тестовых файлов, которые не запускаются по умолчанию, поскольку они могут зависеть от платформы или выполняться слишком долго. Вы можете запустить те или иные дополнительные тесты, задав переменную EXTRA_TESTS
. Например, запустить тест numeric_big
:
make check EXTRA_TESTS=numeric_big