我问：好吧，如何避免测试困难呢？

　　神说，你觉得是大的系统容易测试还是小的系统容易测试？

　　我说，当然是小的系统容易测试。

　　神说，那么，让系统尽可能的小。

　　神说，第一，让需求受控。这是一项很重要的管理工作，如果没有很好的完成这项工作，那么是管理上的失败。

　　我说，这似乎很困难，因为客户总是在要求我们加功能。

　　神说，如果在项目后期要求增加功能，而这项功能又是必需的，那么实际上是在告诉我们需求分析出现了问题，出现了需求遗漏。而一项功能如果终因为各种原因其实不能使用，那么也是需求分析出现了问题，出现了需求幻想，脱离了实际情况。

　　神说，要控制需求的增长，需要决策者、需求分析人员和客户来区分某件事对客户来说真的是必需的，需要价值驱动。

　　神说，第二，不要试图在软件中处理所有的可能情况。

　　我说，我们需要向新系统中导入遗留数据，如果在程序里包含对所有数据的处理，非常复杂，后我们选择了手动处理部分数据。

　　神说，第三，代码质量。好的实现永远是简洁的代码，要尽量减少代码的复杂性。两个具有相同物理规模的程序在内部复杂性上可能有极大的不同，而这终会是决定测试工作难度的主要因素。

　　我说，我们可以通过增量构建，不一次做所有事来控制代码的复杂性。

　　神说，此外要注意组件之间的分离，特别是多团队协作的项目。

　　我说，是这样的，很多项目会划分以模块为单位的小组开发，小组之间、模块之间要尽量减少依赖和不必要的沟通，因此代码可以有冗余，每个开发小组都要各自独立，有自己的分析人员、开发人员和测试人员。

　　提到增量构建，我有了新的问题。

　　我问：我们现在采用迭代式开发，那么每次迭代完成后对客户的演示能不能算是用户验收测试呢？

　　神说，演示不是测试。

　　我说，客户触摸到了真实的系统，直观了解到了系统的功能和使用方式，获取了系统信息，然后进行反馈，这可以看作是部分用户验收测试。

　　神说，对客户来说，如果没有真正的使用该系统，那么没有进行测试。此外，客户获取的信息难道不是你们准备好的吗？

　　我说，演示之前我们会进行准备工作。

　　神说，实际上是在准备客户能够获取的信息。

　　我说，那么理想的迭代开发应该是持续部署？

　　神说，持续部署和持续增量使用。

　　我叹了口气，说，额滴神啊，看起来测试真不是一件容易的事。

　　神说，额滴上帝啊，测试从来没有容易过。