我问：好吧，如何避免测试困难呢？
神说，你觉得是大的系统容易测试还是小的系统容易测试？
我说，当然是小的系统容易测试。
神说，那么，让系统尽可能的小。
神说，第一，让需求受控。这是一项很重要的管理工作，如果没有很好的完成这项工作，那么就是管理上的失败。
我说，这似乎很困难，因为客户总是在要求我们加功能。
神说，如果在项目后期要求增加功能，而这项功能又是必需的，那么实际上是在告诉我们需求分析出现了问题，出现了需求遗漏。而一项功能如果最终因为各种原因其实不能使用，那么也是需求分析出现了问题，出现了需求幻想，脱离了实际情况。
神说，要控制需求的增长，需要决策者、需求分析人员和客户来区分某件事对客户来说真的是必需的，需要价值驱动。
神说，第二，不要试图在软件中处理所有的可能情况。
我说，我们需要向新系统中导入遗留数据，如果在程序里包含对所有数据的处理，非常复杂，最后我们选择了手动处理部分数据。
神说，第三，代码质量。最好的实现永远是最简洁的代码，要尽量减少代码的复杂性。两个具有相同物理规模的程序在内部复杂性上可能有极大的不同，而这最终会是决定测试工作难度的主要因素。
我说，我们可以通过增量构建，不一次做所有事来控制代码的复杂性。
神说，此外要注意组件之间的分离，特别是多团队协作的项目。
我说，是这样的，很多项目会划分以模块为单位的小组开发，小组之间、模块之间要尽量减少依赖和不必要的沟通，因此代码可以有冗余，每个开发小组都要各自独立，有自己的分析人员、开发人员和测试人员。
提到增量构建，我有了新的问题。
我问：我们现在采用迭代式开发，那么每次迭代完成后对客户的演示能不能算是用户验收测试呢？
神说，演示不是测试。
我说，客户触摸到了真实的系统，直观了解到了系统的功能和使用方式，获取了系统信息，然后进行反馈，这可以看作是部分用户验收测试。
神说，对客户来说，如果没有真正的使用该系统，那么就没有进行测试。此外，客户获取的信息难道不是你们准备好的吗？
我说，演示之前我们会进行准备工作。
神说，实际上是在准备客户能够获取的信息。
我说，那么最理想的迭代开发应该是持续部署？
神说，持续部署和持续增量使用。
我叹了口气，说，额滴神啊，看起来测试真不是一件容易的事。
神说，额滴上帝啊，测试就从来没有容易过。
相关链接：
