1、Q1 象限测试，直接叫“单元级别功能测试”不是更好么？我有三个理由。第一、叫组件测试的话，忽略了类和函数。第二、 光和别人说组件测试，别人也可能理解成是Q2的测试。第三、老师在自己的 TDD 课里就是把 Q1 的测试称作“单元级别功能测试”。 2、那么，很自然的，Q2象限测试叫功能测试就不合适了。难道Q1的测试不是功能测试么？Q1也是功能测试，粒度更小罢了。所以，Q2的测试可以称作“系统级别功能测试”，这样就和Q1的“单元级别功能测试”对应上了。 3、不过，Q2 测试更好的名字可能是 Acceptance Test. 很巧，就在老师说的《Succeeding with Agile》里，Mike Cohn推荐了一本书叫《Test driven: TDD and acceptance TDD for Java developers》。这本书里就提到，ATDD (Acceptance TDD) 帮助开发者构建满足商业需要的软件，而 TDD 帮助开发者保障了软件的技术质量[1]。那么，很自然的，Q2的测试可以称作 Acceptance Test. 4、International Software Testing Qualifications Board (ISTQB) 对于 Acceptance Test 的定义是“验证系统是否满足验收条件的测试”[2]。 从这个定义可以看出，Acceptance Test 直接和验收条件相关联，那么，很自然的，Q2的测试可以称作 Acceptance Test. 5、对于熟悉徐昊老师的TDD课程的同学，Q1 和 Q2 的测试还可以有另一套命名。可以看出，本文需求分解的图片和 TDD 课程里的图片极为相似，就是把功能点称作了验收条件。那么，很自然的，Q2 测试可以称作功能点测试，Q1 测试可以称作功能上下文测试。 6、接着第 5 条，通过和本文的图片进行比对，可以发现当年 TDD 课程里的图片其实漏画了 Q2的测试，应该补上。 7、接着第 5 条，那思考题就很简单了，老师讲过。 思考题：你觉得有哪些划分功能上下文的方法？ 方法一、可以通过预先设计（Upfront Design）的架构愿景（比如 MVC）划分功能上下文。这对应了 TDD 的伦敦学派。 方法二、可以通过演进式设计（Evlutionary Design）提取或梳理架构愿景，再划分功能上下文。主要方法是重构，特别是重构到模式（Refactoring to Patterns）。这对应了 TDD 的经典学派。 注释： [1] : Acceptance test-driven development(acceptance TDD) is what helps developers build high-quality software that fulfills the business’s needs as reliably as TDD helps ensure the software’s technical quality. [2]: https://en.wikipedia.org/wiki/Acceptance_testing