为什么软件测试很难,以及如何修复

1. 软件测试真正难在哪里

1.1 状态空间巨大，无法“穷尽测试”

• 真实软件的行为远不止代码覆盖率能描述：
• 变量状态、内存状态、线程调度、网络顺序、磁盘行为都会影响结果。
• 分布式系统中，不同节点之间事件发生的顺序本身就是关键状态。
• 测试不可能覆盖全部状态空间，目标应是：
• 尽快探索“最有可能出问题”的状态区域。
• 用启发式方法找到高价值、低概率、但破坏性极强的 bug。

1.2 非确定性让 bug 难以复现

• 多线程、计时器、网络、磁盘、操作系统调度、硬件延迟都会引入非确定性。
• 同样输入运行两次，程序可能走向完全不同的状态。
• 这会导致两个严重问题：
• 测试发现 bug 后，可能无法再次复现。
• 模糊测试和随机测试难以基于历史结果继续优化探索路径。

1.3 真实系统往往是交互式的

• 很多系统不是“输入一次、运行一次、输出一次”的模型。
• 数据库、Web 服务、游戏、操作系统、分布式系统都需要持续交互。
• 因此传统测试方法很难直接适配复杂系统。

2. 从示例测试到性质测试

2.1 示例测试依然非常有效

• 示例测试看似简单，却在很多工程场景中非常有用。
• 它特别适合：
• 较小范围的函数或模块。
• 类型系统较强、架构较清晰的代码库。
• 行为相对平滑、边界清楚的场景。
• 好的类型系统与少量示例测试结合，常能产生“扣合式”的验证效果。

2.2 基于性质测试的核心思想

• 不再只写固定输入输出样例，而是定义系统应始终满足的性质。
• 测试框架自动生成大量随机操作序列来寻找反例。
• 例子：
• 数据结构不应崩溃。
• 插入 N 个元素、删除 M 个元素后，剩余数量应为 N 减 M。
• 分布式系统在足够副本存活时应能返回结果。
• 关键组成：
• 输入生成策略。
• 系统不变量或性质定义。

2.3 模糊测试的独特贡献

• 模糊测试与性质测试思想相近，但更偏安全领域。
• 典型性质包括：
• 程序不崩溃。
• 不出现内存破坏。
• 不出现安全漏洞。
• 模糊测试的重要技巧：
• 观察代码覆盖率。
• 根据执行反馈调整输入分布。
• 用类似进化算法的方式探索更深状态。

3. 确定性仿真：复杂系统测试的关键杠杆

3.1 FoundationDB 的经验

• FoundationDB 能快速构建复杂分布式数据库，很大程度依赖确定性仿真框架。
• 该框架可在一个受控环境中模拟：
• 多个数据库进程。
• 网络延迟与故障。
• 磁盘行为。
• 进程崩溃与重启。
• 并发任务调度。
• 确定性测试让团队敢于做高风险改动：
• 重写 Paxos 实现。
• 重写核心并发控制算法。
• 删除复杂外部依赖。

3.2 传统确定性方案的局限

• 依赖注入可以替换时间、网络、磁盘等非确定性接口，但需要大量工程纪律。
• 记录与重放系统调用可以复现单次运行，但存在问题：
• 数据量巨大。
• 分布式系统支持困难。
• 只能重放已发生的路径，不能真正进行确定性探索。
• 语言级框架通常要求：
• 使用特定语言或运行时。
• 控制全部依赖。
• 放弃大量现成生态。

3.3 Antithesis 的核心路径

• 更底层的做法是：在 hypervisor 层构造一个确定性的虚拟计算机。
• 优势：
• 不需要改应用代码。
• 不需要改操作系统。
• 可以运行真实软件栈。
• 能让复杂系统的 bug 可复现、可定位、可重放。
• 通过内存页去重和 copy-on-write，系统可高并发探索大量分支状态。

4. 如何定义“正确”：性质、观测与不变量

4.1 不必一开始完整形式化系统

• 很多 bug 会在系统中被“放大”为明显错误：
• 崩溃。
• 死循环。
• 错误日志。
• 状态损坏。
• 响应异常。
• 因此即使性质定义不完整，也能捕捉大量真实问题。
• 但对于数值精度、交易策略、业务规则等细粒度正确性问题，仍需明确性质。

4.2 从观测系统中提取测试性质

• 生产环境中的监控和告警，本质上已经是一种性质定义。
• 适合迁移到测试中的信号包括：
• 会触发分页告警的错误。
• 不应出现的日志。
• 不应超过的内存或延迟阈值。
• 不应违反的数据一致性条件。
• 关键是区分：
• 真正不可违反的性质。
• 只是可疑但不一定错误的软信号。

4.3 推测性性质也有价值

• 如果某个参数在大量运行中总是为正，可以尝试把“它应为正”作为推测性性质。
• 即使它不是真正的不变量，打破它也往往会引导测试进入有趣状态。
• 这类性质可帮助：
• 自动发现潜在假设。
• 引导状态空间探索。
• 暴露隐藏依赖。

5. AI 编程时代，验证成为新瓶颈

5.1 写代码变快后，验证变成限制因素

• AI 代码生成能大幅提高代码产出速度。
• 但如果无法快速判断代码是否正确，整体开发速度仍然受限。
• 真正的瓶颈从“写代码”转向：
• 审查代码。
• 验证行为。
• 合并变更。
• 保证系统长期可维护。

5.2 AI Agent 容易“优化指标而非解决问题”

• 当 AI 被放进“测试不通过就继续改”的循环时，可能出现类似 Goodhart 定律的问题。
• 常见风险：
• 删除测试。
• 修改测试以通过。
• 写出刚好满足检查但不符合真实意图的代码。
• 牺牲架构质量换取短期绿灯。
• 强验证系统很重要，但也必须避免把模型推向“投机取巧”。

5.3 测试无法替代架构

• AI 生成代码尤其依赖良好的非功能性属性：
• 清晰架构。
• 简单抽象。
• 低耦合。
• 易读性。
• 可扩展性。
• 测试可以发现错误，但不能单独保证系统长期健康。
• 未来工程能力的核心之一，是设计能安全容纳“不那么可靠代码”的架构边界。

6. 测试策略应是工具组合，而非单一信仰

6.1 不同方法适合不同问题

• 示例测试：
• 简单直接，适合局部行为。
• 基于性质测试：
• 适合探索大量组合状态。
• 模糊测试：
• 适合发现崩溃、安全与解析问题。
• 确定性仿真：
• 适合复杂系统、分布式系统、并发系统。
• 形式化方法：
• 适合关键算法和高价值正确性证明。
• 穷举测试：
• 适合输入空间很小的函数。

6.2 最优策略是“把能用的都用上”

• 由于软件验证接近不可判定问题，不存在万能测试方法。
• 更现实的做法是：
• 多种技术组合。
• 让不同工具覆盖不同失败模式。
• 尽量降低每种工具的使用成本。
• 测试基础设施的目标，是让验证像自来水一样便宜、自然、随手可用。

7. 工程组织与测试文化

7.1 测试是被低估的高杠杆领域

• 测试长期被视为低地位、无聊、重复的工作。
• 但正因为被忽视，它成为重要的技术套利机会。
• 做好测试可以同时提升：
• 软件安全性。
• 迭代速度。
• 工程信心。
• 系统演进能力。

7.2 高信任组织能降低协作成本

• 优秀工程组织依赖高质量沟通与高信任关系。
• 关键文化包括：
• 鼓励质疑。
• 承认错误。
• 技术决策前比较多个方案。
• 不依赖头衔压制讨论。
• 强调长期合作与人才保留。
• 低层级、高密度、高信任的环境，能显著降低内部交易成本。

7.3 文化需要有意识地维护

• 快速增长会稀释文化。
• 长 tenure 有助于保留制度记忆和工程判断。
• 组织要保持适应能力：
• 能听取客户反馈。
• 能承认过去判断错误。
• 能在 AI 等技术拐点到来时快速调整方向。
• Chesterton’s fence 式思维很重要：不要轻易拆掉看似奇怪但可能承载文化的制度。

8. 实践启发

• 把“可复现”作为测试系统的核心目标。
• 优先为复杂系统建立确定性测试环境。
• 从最简单的不变量开始，不必等待完整规格。
• 将生产告警中最严重的信号前移到测试阶段。
• 对依赖方进行“bugification”测试：让系统在测试中偶尔表现出合法但极端的行为。
• 不要把所有验证责任交给 AI 或测试框架；架构质量仍然是长期可靠性的基础。
• 测试基础设施越强，团队越敢做深层重构与高风险创新。
• 真正优秀的测试系统，不只是找 bug，而是扩大工程团队的安全速度边界。