请收下这波 BDD 安利

发表于 2019-10-17 更新于 2022-01-24 分类于搬砖那些事儿

本文字数： 4.2k 阅读时长 ≈ 14 分钟

首先，听我讲一个关于王铁锤的故事。

版本一

新的Sprint开始了，产品经理/BA 王铁锤召集全组开会💬。

**[王铁锤]**：这个Sprint咱们有个新需求，在网站上做一个用户注册登录功能。现在我来给大家说一下UserStory和AC都有啥。(PS:不知道UserStory, AC(Acceptance Criteria)和Sprint是啥意思的，你需要看看敏捷术语)
20分钟后。。。
**[王铁锤]**：大家有什么问题吗？
**[众组员]**：没问题了👌。
**[王铁锤]**：好，散会。
2天后。。。
**[测试刘翠花]**：咦，李狗蛋，你做的登录页面密码输入框怎么没掩码？密码错了也没个提示？！还有你赵二毛，你做的注册功能还能注册两个一样的用户名？密码长度格式也没限制？！这不符合常理吧，这界面也太丑了点😂!
**[程序员李狗蛋]**：呀，我咋把掩码忘了，错误提示没说要做呀，别着急，我再看看UserStory是咋说的，咦，上边没写😓？！
**[程序员赵二毛]**：唉，这种情况还真没想过，得处理一下，UserStory里也没说这种情况咋整啊，还有密码长度格式上边也没说规则。
**[刘翠花]**：这问题也太多了，当时开会咋就没想到这些呢😕，直接按老王给的UserStory做了。不行，我们得去找他问问。
3分钟后。。。
**[王铁锤]**：呀，这些东西我创建UserStory的时候也没想到。嗯，我得去完善完善。界面显示问题我去找设计师看看。你们等一下。
两周过去了。。。
**[王铁锤]**：怎么样，这个功能做好了吗？客户那边等着呢
**[众组员]**：不行啊老大，我们还有一堆需求和问题没搞清楚，想跟你确认呢
**[王铁锤]**：这咋行呢，原计划这周就得上线呀，唉，都有啥问题，我再看看吧
一个月后，经过王铁锤和众组员的数次沟通确认，功能终于做好了，比原计划推迟两周上线。。。
**[刘翠花]**：唉，上线后肯定又有一堆问题，到时候背锅的就只有我了

版本二

新的Sprint开始了，产品经理/BA 王铁锤召集全组开会。

**[王铁锤]**：下个Sprint咱们有个新需求，在网站上做一个用户注册登录功能。首先讲一下我和客户拟好的用户流程和场景。
5分钟过去了。。。
**[王铁锤]**：相信大家对这个功能已经有了初步的了解，一定也有一些想法。所以在拆分具体的UserStory之前，我想先组织大家玩个小游戏。
**[李狗蛋]**：玩游戏？这么嗨的吗😏，我喜欢。怎么玩啊？
**[王铁锤]**：假设你是用户，列出所有你能想象到的关于注册登录的用户行为场景。并写下这些场景中你希望的系统行为😎。包括但不限于我刚才讲到的场景哦，大家开始吧～
10分钟后。。。
**[王铁锤]**：我看大家都写好了，下面咱们一条一条过，拼凑出一个正常的用户操作流程，然后把相似的场景提取出来，讨论一下哪种方案更好。首先让赵二毛给大家讲下他的场景：

Step1: 进入系统首页，跳出登录注册弹窗.
Step2: 点击注册按钮进去注册页面。
Step3: 填写所有字段并点击注册。
Step4: 弹出注册成功页面，3秒后返回系统首页，用户状态为已登录。

**[赵二毛]**：对，这里我写的是一个注册成功的场景，当然里面还有很多小点需要确认。比如说Step1、Step2、Step4中登录注册页面,以及注册成功页面的前端显示，需要设计稿。还有Step3中的字段需要在设计稿中体现，还需要一些字段的长度格式以及必填规则。Step4中注册成功后有一个3秒的返回延迟，还有返回首页后的登录状态，都是细节问题。
**[刘翠花]**：哇塞，二毛，平时看你写代码也没这么细心啊，想不到你还考虑的这么细多，真棒！
**[李狗蛋]**：二毛写的确实好，基本上涵盖了整个注册流程，跟我写的有很多相似之处。下面我来说说我们的不同点，其他人也可以提出自己的看法。
30分钟后。。。
[王铁锤]：好，大家已经讨论完了。对很多细节和功能已经达成了共识。当然还有一些问题我需要跟客户沟通，寻求他们的意见。很感谢大家提出的思路，很多场景我之前都没有考虑到。比如刘翠花提到的密码输入次数限制问题，狗蛋和二毛也从代码方面提供了自己的想法。我受益良多👏。对于我们在功能方面达成的共识，还有一些需要确认的问题，已经拍照留存，我之后会整理好给大家分享，散会～
2天后。。。
**[王铁锤]**：前两天大家讨论了下注册登录模块的具体流程，其中包含要实现的功能和细节。设计图和一些遗留的问题我都确认过了，并且写好了UserStory还有AC。接下来大家对比上次会议结果一起看一下。确认大家的理解一致，没有遗漏的点。
20分钟后。。。
**[王铁锤]**：大家有什么问题吗，我有没有漏掉什么点？
**[众组员]**：没问题了👌。
**[王铁锤]**：好，看来都清楚了，散会～
一个月后，由于大家对登录注册功能的实现细节已经达成了一致。不仅比原计划提前一周完成，还提出了更多可以改进的功能，得到了客户的赞赏和肯定。

啥是BDD

定义

相信通过上边的例子，大家心里应该知道BDD是啥意思了。

BDD行为驱动开发(Behaviour-Driven Development)
是一种软件开发流程，这里’行为’指用户行为。’开发’指整个开发团队。顾名思义，BDD要求开发团队严格按照具体的、符合现实情况的用户行为进行开发，不断减小项目组成员在业务与技术两方面的理解差异，使团队对软件应该有的行为达成一致。

BDD与敏捷

我们知道，敏捷是现在最流行的软件开发框架，可以快速、稳定的进行软件开发。而BDD相当于是这个框架一个强有力的插件，能够帮助我们更高效地实现敏捷开发的目标。

就像上边故事的两个版本，都实行了敏捷实践。但版本二中的团队同时实行了BDD，因此产生了更好的结果。

类似定义对比

TDD: 测试驱动开发，敏捷开发的特点之一，概念上与BDD同级。但在实行过程中，团队必须在保证TDD的基础上施行BDD，否则只能是捡了芝麻丢了西瓜。
FDD: 功能驱动开发，是一种敏捷开发流程，概念上在BDD上级。

为什么要BDD

没有BDD以前(版本一)

技术人员(程序员/测试)对整个用户流程不熟悉，只分散开发具体的功能，没有产生业务价值的连通性，容易对需求理解产生歧义。
业务人员(产品经理/BA)对功能具体实现流程不熟悉，影响下一步需求的提出和产品交付。
两种角色对用户流程和业务需求的理解不一致，容易导致产品返工，而且需要浪费更多时间相互沟通。

有了BDD以后(版本二)

项目组成员对用户流程、开发顺序以及实现细节有一致的理解，可以更快速高效的交付产品。

怎么做BDD

要做好BDD，需要三步实践。

探索：做什么

第一步，开个会大家商量一下要做啥，执行者是整个团队。

还记得上边王铁锤让大家玩的游戏吗？其实这个游戏有个洋气的名字，叫做：Discovery Workshops。不像之前王铁锤直接拆分好UserStory告诉大家，DiscoveryWorkshops的关键在于让大家聚焦真实、具体的用户场景，一起决定业务规则和验收标准。动员大家去发现、定义系统该怎么工作。这么做的好处有：

把团队不同角色对功能的理解误差暴露出来
BA/产品经理可以确认开发团队完全理解业务规则和细节
帮助BA/产品经理更好的确定UserStory的粒度
有了测试人员的介入，可以帮助预防一些bug的产生，而不是在产品开发完后再去找同样的bug。

要做好这个Workshops，有几点很重要：

在功能开发前的一两个Sprint进行。
从用户角度出发，关注具体、真实的业务场景。
总结大家对业务细节的不同看法和问题，暂时不能解答的要确认后再通知大家。

记录：怎么做

第二步，用程式化的文档把讨论结果记录下来，执行者一般为BA/产品经理。

在敏捷里，其实就是把讨论结果拆分成UserStory，并把验收标准写在UserStory中。然后再组织大家开个会，确认一下有没有遗漏的问题。这样做的好处有：

提供一种快速的方法，再次确认大家的理解一致。
对UserStory的粒度和验收标准得到更多的反馈。

检验：做了啥

第三步，根据拆分好的UserStory和验收标准，把不同用户场景编写成自动化测试，执行者一般为测试人员。

其实对于测试人员而言，这种是理想情况，因为在实际开发过程中，可能没有足够的时间来提前写好自动化测试。但最好还是在开发结束之前写好，这样做的好处有：

帮助团队跟踪功能完成度

好的自动化测试应该涵盖主要业务流程和场景。所以在开发工作完成前，失败的测试可以发现bug,也可以时刻提醒团队有哪些功能还没有开发完成。就像TDD，可以帮助开发在class,method层面发现问题。

减少测试工作量

像所有自动化测试的优点一样，它可以大大减少手工测试的工作量，后期还可以用来做回归测试。因此测试人员会有更多时间做更有价值的事情，比如关注一些不能自动化的功能、探索性测试、准备下一个功能用户场景的自动化等等。

系统功能维护和查询

好的自动化测试也应该像一份业务文档。有时候我们忘记了之前某些功能的业务规则是什么，就可以通过查询关于此功能的自动化测试找到答案。或者团队需要对某个功能进行维护或重构，也可以查看自动化测试，看看它现在是怎么工作的，与它相关的功能还有哪些，以确保不会影响别的功能。

对BDD的常见误解

不需要做Discovery Workshops

如果没有一个大家一起探索功能的过程，那就不叫BDD了。就像故事的版本一，所有的User Story都由一个人(BA/产品经理)发现并编写，这就违背了BDD的灵魂：共享理解。

三步实践的顺序可以调换

如果没做Discovery Workshops，那直接拆分UserStory就是在浪费时间。如果没有拆分好UserStory，确认好验收标准，也就不能编写自动化测试了。所以，这三部实践必须按顺序做，否则不会达到我们想要的结果。

代码写完后再写自动化测试

其实现在大多数情况，都是等代码写完之后再进行自动化，这当然很合理。但这样也就不是BDD了。

谁把钱丢了