◆ 系统设计

　　在测试用例中描述系统的行为，体现出系统的每一步操作所带动相关事件的触发，进而得到相关的结果，这是对一个产品详细的定义，也要求我们在测试用例中对系统的行为做出详细的设计。

　　◆ 合作

　　客户，需求分析人员，测试人员，和开发人员之间的合作，这个合作时间较集中在项目的开始阶段，大家一起对系统的行为进行定义，测试发展起步较晚，到现在开发人员还是有很多不重视测试，再加上测试人员的工作是找出他们代码中存在的bug，所以开发人员和测试人员需要很多的相互沟通理解，处理好关系，这样的合作，无疑提供给我们交流很大的一个空间。

　　BDD的测试方法

　　关键字：故事&场景，通用语言。

　　◆ 故事&场景

　　一个故事描述了系统的一个行为，对应着用户的一个需求。举例说明：外部开发者开发好的应用经过小二的审核后发布在淘宝开发平台的服务平台上面，供用户订购使用。现在有一个用户要访问一个应用，此时发生了一个故事，用户访问应用要经过top-container应用容器的校验，这个故事中描述了top-Container做校验的行为。

　　在一个故事中又会有多个不同的场景。用户访问应用时，用户和应用之间有很多种条件需要满足，每一种不同的情况都对应着一个场景。举例说明：用户在没有订购此应用，并且此应用恰好又需要订购才能够访问，这种情况下，top-Container拒绝其访问；再比如，用户没有订购过这个应用，此应用是一个基础应用不需要用户订购，这种情况下，top-Container容许其访问。

　　故事和场景的作用是定位，故事定位要描述系统的功能模块，场景定位要描述该功能模块下哪种条件下的系统行为。

　　◆ 通用语言

　　语言是用于沟通，向别人表达自己的意思的工具，我们的基于BDD的测试用例的代码描述着系统的一个行为，可以按照传统的写法将这个行为描述清楚，但是别人来看时，肯定要花不少的精力。所以BDD提供一个通用的模板，并且要客户，开发人员和测试人员一起定义一套通用语言来做描述，这样做，既可以方便测试人员自己写测试代码，也能方便别人看懂，也可以为开发人员的实现代码提供类名，方法名。

　　示例

　　通用模板示例：

　　Story： 标题（描述故事）
　　As a [角色]
　　I want [特征]
　　So that [利益]
　　Scenario 1： 标题（描述场景）
　　Given [上下文]
　　And [其他上下文]…
　　When [事件]
　　Then [结果]
　　And [其他结果]

　　举例说明：

　　Story： 用户访问应用
　　As a 用户
　　I want 访问淘宝开放平台的一个应用
　　So that 我可以使用这个应用提供的服务
　　Scenario 1： 用户未订购此应用
　　Given 一个应用
　　And 此应用需要订购才能访问
　　And 用户没有订购此应用
　　When 该用户访问此应用
　　Then 访问被拒绝
　　And 返回用户没有订购此应用的错误码及错误信息。

　　BDD的优势

　　1. 代码即文档，由测试用例管理需求，大限度的消除项目团队人员对需求理解不一致。

　　2. 由测试代码监督，约束着开发代码。开发者需要时刻考虑去满足测试的需要。这样使得开发者的代码保持着方向的正确性，也使开发者的代码足够的精练，产生较少的垃圾代码。

　　3. 开发者需要设计良好定义的接口，来满足测试的需要，降低系统模块的耦合度。

　　4. 有测试用例的保障，系统代码可以放心的重构。

　　5. 增强开发者的信心。一个测试用例的通过标志着系统一个需求的实现，这样的成果可以增加开发者的成感与信心。

　　BDD的缺点

　　1. 测试用例只能体现系统细节设计，不能体现系统总体设计。

　　2. 测试用例无法覆盖全部的测试工作。

　　3. 约束开发者的发挥，开发者需要时刻考虑能否满足系统行为，能否使测试用例通过，这样会局限创造力。

　　4. 项目初期在测试方面投入过多，引起开发人员的不满。这一点上尤其对于新近实行TDD理念的团队来说，这方面的怀疑更多。

　　总结

　　BDD基于TDD发展起来，具有很好的实践基础，并且越来越多的人开始接触并且接受其的测试理念，受到了很多人的热捧。

　　个人认为，我们可以在小范围内用BDD的方式来开展项目开发工作，然后看效果，调整成为符合我们公司开发需要的方式，进而推广。

　　在我们的日常测试中，我们也可以借鉴其系统设计的概念，将我们的测试用例设计成可以体现系统行为的风格，这样做的好处有两点，一是方便维护，别人一看懂得我们的测试用例的校验点在哪里；二是方便我们定位问题，导致用例不通过的原因是系统的哪一步处理出错，不需要我们调试跟踪直接看出来，可以节约我们大量的时间。

　　后，用一个博友的话来总结BDD：优美的测试代码，是一个个优美的故事。也用一句话说出我们所有测试人员的心声：我不做软件，但我使软件变得更好！