测试中为何使用三角测量法而非随机值？

• 可复现的故障定位：随机值测试遇到失败时，由于每次运行的输入不固定，很难复现问题、定位根源。而三角测量法使用固定的、有代表性的测试用例，比如test_add_positive_numbers(2, 3, 5)、test_add_zero(0, 0, 0)、test_add_negatives(-1, 2, 1)，一旦测试失败，能立刻锁定是哪个场景出了问题，排查效率大幅提升。

• 精准的场景与边界覆盖：三角测量法通过刻意选择不同维度的测试用例（正常场景、边界值、异常输入）驱动实现，确保覆盖所有关键逻辑。随机值测试依赖概率，可能长期漏掉核心边界（比如大数溢出、负数运算、零值处理），而三角测量法可以主动把这些场景纳入测试，让实现自然适配所有必要情况，而非靠随机碰运气。

• 循序渐进的实现与重构保障：TDD的红-绿-重构流程中，三角测量法是逐步验证实现的关键。比如先写1+1=2的测试，用硬编码返回2通过；再写2+3=5的测试，逼你把实现改成真正的加法逻辑。每个测试都是重构的“锚点”，后续修改代码时，只要所有测试通过，就能确保原有功能没被破坏。而随机值测试跳过了这个逐步验证的过程，一旦实现有漏洞，很难快速定位问题环节。

• 清晰的测试文档价值：三角测量法的测试用例本身就是可读的文档。别人看测试代码时，通过test_add_zero、test_add_large_numbers这类命名和固定输入，能立刻明白函数需要处理哪些场景；而随机值测试的输入是动态生成的，无法作为静态文档，只能传递“处理任意输入”的模糊信息，无法体现具体的需求边界。

• 避免过度实现：三角测量法是“测试驱动实现”，你只会实现当前测试要求的功能，不会提前做过度设计。比如实现折扣计算时，先写“满100减10”的测试，用硬编码返回90；再写“满200减20”的测试，才改成按比例计算的逻辑。而随机值测试一开始就要求适配任意输入，很容易让你提前实现超出需求的功能（比如支持小数、多级折扣），增加不必要的复杂度。

针对你提到的“繁琐”问题：三角测量法并不需要删除“多余测试”——那些用来驱动实现的不同场景测试，都是长期有价值的回归保障。所谓“临时测试”只是初期为了突破硬编码的过渡，只要是覆盖关键场景的测试，都应该保留下来，成为后续维护的依据。

内容的提问来源于stack exchange，提问作者Opack