如何参与 Beta 测试

来自 PostgreSQL wiki
跳转到导航跳转到搜索


如何参与 Beta 测试

如果您不是代码贡献者(即使您是),测试 PostgreSQL Beta 版本也是您可以为我们的项目做出的最棒的事情之一。通过参与有组织的测试,您可以帮助更快地发布版本,并带来更多功能和更少的错误。

测试前提条件

A. 拥有测试机器:可以运行 PostgreSQL 数据库和/或应用程序测试的机器,即使测试可能会使用您的所有计算机系统资源,或者导致崩溃。如果您的公司使用 PostgreSQL 并且您有用于开发变更的测试环境,这是理想的选择。

B. 拥有测试用例:可以运行的应用程序测试、接口测试、性能测试和/或数据库功能测试。请参阅以下内容以了解解释或建议。

C. 拥有时间:在新的 Alpha 或 Beta 版本发布时进行测试。不需要很多时间,但每次发布时都要预计花费几个小时进行测试,并解答 PostgreSQL 开发人员提出的问题。

9.6 中需要重点测试的内容

9.6 具有许多新功能和许多变更。以下列出了 PostgreSQL 开发人员认为可能需要特别注意的一些内容。

需要测试的新功能

以下是全新功能。请尝试使用这些功能;它们是否按照文档描述的那样工作?它们是否相互兼容?默认值和参数是否合理(如果适用)?新功能可以相互使用吗?

  • 并行查询
    • 并行顺序扫描
    • 并行联接
    • 并行聚合
  • postgres_fdw
    • 排序下推
    • 联接下推
    • DML(UPDATE/DELETE)下推
    • 扩展级联支持以安装依赖项
  • 同步复制
    • 新的 remote_apply 复制模式,该模式将等待确认备用服务器已应用更改
    • 支持多个同步备用服务器
  • 事务、VACUUM 和可见性映射
    • pg_visibility 扩展用于检查可见性映射
    • 可见性映射中的冻结页面数据,用于跳过已冻结数据的真空操作
    • 用户定义的快照过期时间,用于控制表膨胀
  • 其他功能
    • Cube 扩展 kNN 支持
    • 命令进度报告
    • pg_stat_activity 中的详细等待信息
    • 用于部分索引的仅索引扫描
    • 短语全文搜索

请参阅 什么是新功能 wiki 页面,以获取有关如何使用这些功能的信息,以及 发行说明

性能改进

以下 PostgreSQL 性能领域预计会得到显著改进。您的性能是否得到提升?性能是否真的变差?请进行测试。

  • 针对 CREATE INDEX、CLUSTER 和查询执行对文本和数字字段进行排序的大幅速度改进。包括内部和外部排序。
    • “缩写键”优化可以通过运行“set trace_sort = on;”并查看服务器日志(或通过运行“client_min_messages = 'LOG'”来自 psql 查看 psql 客户端的日志输出)来提供有用的调试信息。按类型进行的检测可以很好地指示为什么优化可能不适用于某些特定数据集。
  • 对哈希创建和查找性能的改进
  • 多核和大内存可扩展性的显著提升
  • WAL 压缩,用于更小/更快的交易日志

潜在的回归

以下领域已被标记为可能导致某些用户平台和应用程序出现回归或崩溃的领域。请测试它们是否会导致您的回归。

  • 排序:排序改进是否在您的平台/编码上失败或出现回归?
  • 测试在 WAL 压缩打开的情况下从二进制备份(PITR)进行故障转移和恢复。它是否仍然有效?是否存在数据损坏?
  • 运算符优先级的更改是否会改变您的查询结果?
  • PL/pgSQL 中的强制转换行为更改是否会破坏您的函数?
  • REASSIGN OWNED 和 ALTER OWNER TO 是否现在可以正确设置更改对象上的权限?
  • 您是否可以通过利用新的安全漏洞侵入 Postgres?请将所有安全问题报告给 [email protected]
  • 备份和还原是否可以与 RLS 安全的数据库一起正常工作?

文档审查

我们尽力尽可能好地记录新功能,但错误可能会发生。此外,文档中可能缺少一些细节,或者不清楚或误导。您可以使用以下命令查看新添加的文档

  • git log -p remotes/origin/REL_11_STABLE..master -- doc ; 或者,
    • 这将显示单个提交,其中包括中间更改和错误(例如:实现功能 ; 重新排列文档 ; 修复错别字 ; ...)。
  • git diff remotes/origin/REL_11_STABLE..master -- doc
    • 这仅显示先前版本和要测试的版本之间的文档差异,因此会丢失提交粒度,但可以避免显示另一个提交已解决的中间问题。

已知问题

PostgreSQL 9.6 Beta 中存在一些已知问题。这些开放问题已单独记录。在寻找代码中的类似错误时,它们可以提供一些启发。

可以运行的测试类型

安装测试

这是最简单的测试,并且优先于其他所有测试。安装新版本的 PostgreSQL。使用您喜欢的选项和 contrib 模块以及外部工具对其进行配置。它是否都能正常工作?

自定义应用程序测试

如果您已经在生产环境中使用 PostgreSQL 来运行您的自定义应用程序,请尝试将您的应用程序移植到新版本,并运行您自己的应用程序测试和性能测试。尝试升级填充的数据库副本,并查看是否出现任何升级错误。告诉我们您发现了什么。

当然,如果您的应用程序具有完整的测试框架,该框架允许您对应用程序功能及其整体性能进行单元测试,那么这将更有价值。但是,即使对升级进行一些临时用户测试也很有帮助。

通用应用程序测试

一些流行的开源和专有应用程序附带了自己的测试套件、单元测试和/或性能测试。在某些时候,我们将有一个这些应用程序的列表;如果您知道其中之一,请将其添加进来。对于这些应用程序中的每一个,您可以测试以下内容

  • 升级填充的数据库
  • 使用软件的安装程序创建新的数据库
  • 运行单元测试并查找错误
  • 运行性能测试并查找性能回归

具有测试框架的开源应用程序

  • Rails 应用程序
  • Python 应用程序
    • Django
  • ORM
    • SQLAlchemy
    • DataObjects
    • DataMapper
    • ActiveRecord
  • PHP 应用程序
    • phpPgAdmin
  • Perl 应用程序

接口测试

没有驱动程序就无法使用 PostgreSQL,我们希望确保所有驱动程序都能与每个新版本的 PostgreSQL 尽可能好地工作。我们特别希望确保新功能不会破坏这些驱动程序。幸运的是,许多驱动程序都有回归测试。

因此,下载您最喜欢的驱动程序的最新版本(也许还有一些您不太喜欢的驱动程序,但它们仍然是当前/流行的),将它们指向新版本的 PostgreSQL,然后运行回归测试。然后,使用新版本的某些功能构建一个简单的数据库,并尝试查询它们;新的语法或新的数据类型是否会破坏驱动程序?

性能测试

另一个需要检查的关键事项是性能回归和改进。测试此问题的难点在于您确实需要确保以产生可重复结果的方式进行测试,否则性能指标将毫无意义。这意味着您应该在除了测试之外没有任何其他运行的系统上运行测试,您应该运行测试几次,并查看结果是否一致,等等。您还需要针对先前版本(例如 8.4.4)和当前的 alpha 或 beta 运行测试或基准测试。

可以运行的性能测试包括

  • 应用程序性能基准测试,如果您的自定义或公共应用程序有一个基准测试。
  • pgbench。稍后将提供有关如何从 pgbench 获取有用结果的说明。
  • 真实的基准测试,如 DBT2、Spec 的 EAStress 等。这些需要大量时间和服务器硬件才能运行。
  • 特定任务性能;尝试运行您知道会占用 PG 资源的操作(例如 40 表联接或 ELT 操作),或者运行在新版本中预计会得到改进的操作。

如果您开始运行性能测试,则务必在整个 alpha/beta 循环中坚持下去,以便我们能够查看性能是否得到提升和/或是否已修复任何问题。

功能测试

每个 alpha 或 beta 版本都有新功能。虽然我们的贡献者在隔离的情况下很好地测试了每个功能,但对每个新功能与每个其他新功能以及与旧功能进行组合测试的组合数量对于开发人员来说是不可行的。此外,我们离代码太近,可能会错过文档中遗漏的主要内容。这就是您发挥作用的地方。需要测试的内容

  • 选择任何您以前从未听说过的新用户界面功能。尝试完全根据文档使用它。报告结果、问题和建议的文档更改。
  • 选择两个或三个可以以某种方式组合起来的新功能(例如联接移除和分区联接,或者 DefaultACL 和列触发器)。尝试运行一个组合了这些功能的脚本或查询。查找错误或非规范或令人困惑的行为。报告测试过程和结果。
  • 选择任何一个新功能和一个旧功能,该旧功能要么很复杂(例如 Tsearch2),要么是在最近几个版本中添加的(例如窗口函数)。将它们结合起来,报告你如何操作以及结果。

同样,重要的是你要跟进你所报告的任何问题的修复。

如何测试

1. 第一次运行特定测试时,你可能需要将其发布到 pgsql-testers,以便其他测试人员可以建议调整以使测试更有用。

2. 编写测试脚本,以便你可以重现它。

3. 运行测试并将结果收集到日志中。

3.a. 如果你需要,可以在旧版本上运行测试以进行比较。

4. 复制下面的电子邮件模板,并使用模板将结果发布到 pgsql-testers。

5. 关注你的测试的后续情况并作出回应。

6. 等待下一个版本发布并再次运行测试。

报告测试

你可以通过电子邮件报告测试。你可以在 订阅表格 中订阅任何 PostgreSQL 邮件列表。请注意,你也可以在没有订阅的情况下发布到邮件列表。

  • pgsql-bugs: 如果你认为在测试版中发现了 bug,这是首选的邮件列表。你也可以使用 错误报告表格
  • pgsql-general: 大多数进行测试的用户应在此处报告他们的测试结果。
  • pgsql-hackers: 如果你已经订阅了 pgsql-hackers,欢迎在这里发布 bug、问题和成功的测试报告。请注意,pgsql-hackers 是一个流量很大的邮件列表,其中包含许多开发讨论。

报告内容

请尝试在你的电子邮件中包含以下所有信息

姓名

版本


测试类型


测试详情


平台


安装方式


平台详情


测试步骤


失败?


测试结果


评论


各字段内容

姓名 你的姓名,以便我们能够跟踪谁在进行哪些测试,因此如果你使用昵称,请保持一致。同样,如果你进行大量测试,你可能会在发布说明和/或贡献者页面中获得认可,因此你可能希望提供你的真实姓名。

版本: 你测试的特定版本。必填。

测试类型: 这是什么类型的测试?如果是组合测试,请勾选多个选项。

测试详情: 对你运行的测试的简短描述。例如,“SQLAlchemy 单元测试套件”或“pgBench”或“组合同步复制和非日志表”。必填。

平台: 你的操作系统。

安装方式: 你是如何安装 alpha 或 beta 版本的?

平台详情: 对你运行测试的平台的简短描述。例如,“MacBook Snow Leopard 64 位”或“Linux 16 核 Sun 4600 配备 NAS 存储”。可选。

测试步骤: 如果测试步骤不言而喻,则需要提供重现测试的步骤。可选。

失败: 测试是否显示了兼容性问题、错误或性能下降?或者其他 PostgreSQL 开发人员应该关注的问题?必填。

结果: 关于你如何运行测试以及发生了什么的叙述。如果你遇到错误,请粘贴详细的错误消息。

评论: 上面未包含的任何其他相关信息。可选。