PostgreSQL 测试头脑风暴：PGCon2013 非正式会议笔记

构建农场 - 由“动物”组成

• 目前每个动物运行多个实例；每个动物配置它构建的 contrib 模块（通常基于平台限制），但所有测试都运行
• 目前不支持机器到机器测试（但是，您可以跨两个本地实例运行复制）
• Peter Eisentraut 一直在使用 Jenkins 做很多工作

关于收集关于在何处发现和修复错误的数据以确定问题区域热图的问题；讨论偏离了关于该项目有意识地缺乏错误跟踪器的讨论；可以使用错误电子邮件中的标记来启用一定程度的分析

客户端测试（超越 psql）；libpq 已测试，这就是 Python、PHP、Perl 等通常构建的基础，但这些客户端可能没有进行重要的自动化测试；但是，这通常被认为超出了 PostgreSQL 项目本身的范围

据称正在进行对生成的 SQL 等进行自动化模糊测试，但该项目只有在发现问题时才会听到它

性能农场

• 希望进行整体性能测试（包括吞吐量/压力测试）；Mark Wong 已经在使用 DBT2 每两周进行一次（因为设置/拆卸很困难）
• 希望进行单个 SQL 查询回归测试，以防止将来发生像 9.2 子查询性能回归这样的灾难
• 唯一阻碍的是编写性能测试基础设施的_时间_；硬件_是_可用的（并且可以专用于性能目的以提供一致性）
• 构建农场已经具有报告基本分析信息的功能，像 iozone 这样的工具将有助于过滤奇怪的现象