在四种软件开发模式中，除了 TDD，还有 BDD、ATDD 等很多相似又不同的开发方法，其中写测试的入手点和颗粒度也各有不同。这也是进阶高级开发需要了解的内容，今天的问题是：
①各种视角和颗粒度的测试如何配合？
②各种颗粒度的测试比例应该如何搭配？
③比例失调的时候应该如何调整？
我们在软件开发的过程中，测试或多或少都会以不同的形式存在。
有些是以脚本或代码存在，有些可能只在我们的意识中同时在验证的时候操作。所以不同的测试在不同阶段有着不同的目的。
- 当我们在开发过程中的时候，就需要单元测试；
- 当进行模块间集成的时候就会用到集成测试；
- 当你集成完备就需要UI，或者e2e测试。
一般从不同的角色角度验证功能又分为 uat, bat , pat 等。
但所有测试的目的都是为了质量，所以它的角度和粒度是对质量保证的态度，也就是说在对测试的分配中取决于团队的质量保证策略。
ATDD是验收测试驱动开发。
这里我以一张任务卡为例，ATDD 在工作中会在开任务卡的 “kick-off” 和 “sign-off” 环节，BA、QA、DEV 来形成一致的验收标准，主要关注输入和输出结果，从而证明功能是实现期望的验收条件的。
BDD原本是业务用来描述清楚一个功能点的。
用在开发过程中，开发人员使用 BDD 也能够清晰的描述清楚一个小的功能在点的背景、输入、输出。
在实际应用中，我们会针对任务卡清晰列出验收点。验收标准统一后，在开发人员开发任务之前，会做 Tasking，Tasking 的格式可以按照 BDD 的格式整理，描述清楚 given-when-then。
进入到 coding阶段，会按照 Tasking 编写测试用例，测试用例的编写我们会遵循 BDD 的格式，描述测试的输入、输出、上下文。并通过高层需求驱动出底层的实现。在功能开完成时需要对开发的整体进行 E2E 的测试保证测试用例。
单纯的 ATDD，由于其粒度较大驱动出来的代码，内部更容易逐渐会形成泥球。TDD 粒度非常细，刻意练习后能更容易维护好 clean code 。
那具体各种颗粒度的测试比例应该如何搭配呢？可以从下面三个方面来考虑：
- 优先堆运行时间短、维护成本低的测试，例如单元测试，因为性价比高；
- 重要且核心的功能，可以有选择性地堆到集成测试和 “e2 ”；
- 金字塔上层测试，可以有选择性的覆盖重要功能即可。
但具体如何搭配要看团队的具体情况，也要看项目的复杂度。原则是越全面越好，但有时候也无能为力。
单元测试是白盒测试，它的原则是如果每一行代码都是正确的，那结果肯定也是对的。
e2e 测试趋向黑盒测试，我不管如何执行，我有一个条件，同时也知道该有的结果，来判断功能的正确性。
一个是从过程中保证质量，一个是从结果中保证质量。就敏捷而论，过程中保证质量更好。
所以你可以单元测试不够，e2e 不够，但整体加起来要覆盖完整。自动化如果不够，手动补上， 要保证发布的功能都有质量保证。
颗粒度比例失调该怎么调整呢？
首先应该清晰目的和失调的原因。有的失调是特意用技术债去换取其他方面的利益价值。
在团队组织中可以分阶段来调整各类测试的比例。团队基础能力不足或者项目时间紧迫可以使用 ATDD ，使用 ATDD 时一定要记录技术债，定期偿还技术债。
总的来说测试金字塔中各类测试有其成本，也有其价值。工作中根据实际情况调整，刻意练习时，则忽略掉那些所谓的时间约束限制，一心练习。
以上内容整合自【极限编程中国 | 实践者】 微信群22日讨论，内容贡献者： 
现在还有名额免费加入
【极限编程中国 | 实践者】微信群
和前ThoughtWorks总监咨询师熊节实践敏捷开发
原文链接：https://mp.weixin.qq.com/s/Z5R5cpRTKwgBk7AvU371lw
若有收获，就点个赞吧
0 人点赞
