某项目在敏捷转型之后也开始推进TDD实践，团队专门挑选了两三个技术骨干第四象限，搭建了单元测试框架，然后要求开发人员在开发之前就用TDD的思想编写相应的单元测试用例。
一年后，当我们回顾团队的工作时，发现代码质量并没有太大的提高。按理说，早期的测试和测试驱动开发应该可以提高代码质量。发生了什么？
通过沟通、访谈我们发现：
1）有时候很多同学为了赶上项目进度，忘记写相应的测试用例；
2）单元测试用例都是开发人员自己编写的，往往一个功能就是一个单元测试用例；
3）故障代码变更合并后，将无人负责补充相应的单元测试用例；
4）......
我想很多人看完这篇文章都会感触颇深，你们同意我的观点吗？单元测试是支持团队开发质量的好方法。我们有好的想法，也有很多好的工具来支持它，但怎么用它取决于人。它很容易用，但怎么用好，让它真正有效，需要我们去思考。或许，它是测试人员协助开发人员编写和维护单元测试用例的好方法。
象限 2：支持团队的业务导向测试
目的：定义和验证外部质量，并帮助我们了解何时完成。
核心实践：ATDD、BDD
注意：面向业务的测试也称为“面向客户”、“故事”、“客户”和“验收”测试。“验收测试”这个术语特别令人困惑，因为它会让一些人想到敏捷开发中的“用户验收测试”。验收测试通常是指面向业务的测试，但它也包括第四象限中的面向技术的测试，例如客户对系统性能或安全性的要求。
解读分享：现在做BDD的团队已经不多了，目前知道的国内有来自BAT的团队在做正常的尝试留学之路，具体的实现情况还不清楚，所以这里就不讨论BDD了。
怎么理解业务导向？
面向业务意味着面向客户，而客户需求往往只是一句话或者一种模糊的感觉。面对这样抽象的需求，开发团队往往很不适应，生产出来的产品不符合客户要求，经常面临返工。ATDD 通过需求实例化的思想，避免了抽象带来的理解偏差，从业务层面支撑团队的开发。
最近，A团队在做ATDD，SM抱怨需求实例化输出的验收项太多了，有点吃不消，而且这么多验收项很痛苦。团队QA也提出疑问，说既然验收项这么多，那我后面还需要测试设计吗？
这其实暴露了需求实例化实践中的两个问题：
1）实例化的场景容易碎片化，在功能层面需要进行领域建模来映射下一层的需求，如果这部分做得不好，会导致下一层的需求碎片化，给后续的需求分析和方案设计带来困难。
2）与原有的测试活动存在一定的冲突。
该怎么办？
我们的测试小伙伴能不能先往前走，提前和BA、DEV一起做需求分析、测试分析，帮助团队通过测试将需求实例化。通过测试分析，进行功能划分和整理，将碎片化的验收项整合整理第四象限，输出一个完整的、大家容易理解的验收项，这也是一份测试设计文档？
也许只有通过实践，我们才能更深刻地领悟其中的奥秘和解决方案。ATDD是一种非常实用的方法，需要我们不断的实践和探索。
象限 3：面向业务的测试，用于评估产品
目的：
测试人员或业务用户通过实际与软件交互，从整体业务的角度来评估产品。
核心实践：
探索性测试
注意：人总会犯错。只有真正使用软件并与之交互，才能真正客观地评价软件，避免想象力带来的干扰。象限 3 大部分是手动测试，但如果没有象限 1 和象限 2 中的测试，您将没有时间进行象限 3 测试。
