开发人员和测试人员协同BDD实践

  一个具备完整测试生态系统的团队会在不同的测试层面有相应的布局，针对客户需求，有验收测试；针对接口，有接口测试；针对开发，有单元测试等等。

  就开发团队来说，美好的期望是团队中的每一个人都有很强的质量交付意识，都能够坚持内建质量。然而，坚持内建质量是困难的，在各种压力下，就单元测试而言，很难每一个人都切实践行。

  对测试团队，如果长期处于基础的手工测试显然是不行的，当测试团队成长一些后就开始探索自动化测试，对于一些比较上进的测试同学来说，提升业务能力和自动化能力的期望尤为强烈。

  针对客户端的自动化测试，从测试团队的角度来看，UI自动化测试是很直观想到的自动化方案，如果实践的成功，可以很大程度的减轻手工测试的压力，然而UI自动化的坑实在太多，其成果也难以衡量。除却UI自动化测试，以测试功能为主的BDD是减轻手工测试压力，提升测试团队能力的一种可以尝试的方式。这里的BDD相对于开发过程中的TDD是针对不同层面的测试，TDD关注点在函数，对于推动开发者优化设计，内建质量很有帮助。BDD不关注函数实现细节，只关注功能点，其基本目的是覆盖业务的功能需求，减轻测试团队回归测试的压力。从实现测试用例的难度上讲，BDD难度相对低于TDD，对于一个设计不算特别烂的模块来讲，BDD难点在于业务分析和用例设计。

  对于客户端程序，其呈现形态基本可以抽象成下图的描述;

image10.png

鉴于UI自动化的各种问题，这里的BDD不关注UI交互，只关注核心业务功能的测试，也就是下面这样子：

image11.png

  开发人员没有足够的时间写用例，测试人员急切希望提升自动化能力和业务能力，那么培养测试团队在BDD中用例设计和实现部分的能力或许可以起到不错的效果，至少，这绝对是值得投入资源实践的思路。

  这期间可能会遇到各种各样的问题，下面是可能有用的流程：

Step0

• 测试人员和开发人员结对分析业务，识别功能点
• 输出功能点列表

Step1

• 开发人员做架构设计和详细设计
• 测试人员针对每个功能点设计用例
• 分别输出设计说明（设计图、设计说明书、代码结构等）和用例列表

Step2

• 开发人员设计评审，测试人员全程参与
• 测试人员用例评审，开发人员全程参与
• 分别输出最终设计和最终用例

Step3（可选）

• 开发人员和测试人员进一步沟通设计
• 基于用例，开发人员和测试人员进一步沟通API

Step4

• 测试人员实现用例
• 开发人员复审代码

以上是建议的基本实践步骤，对于刚起步的团队，以下是一些可能有用的建议：

1. 和测试人员沟通设计和实现时，开发人员保持更多耐心
2. 前期的用例实现开发人员和测试人员结对，后期测试人员独立编写，但是和开发人员邻座工作
3. 针对每个功能的首个用例，都由开发人员和测试人员结对编写，作为其余用例的模板
4. 用例描述省略掉对结果的描述以提高效率，只需描述功能即可（即省略掉Give、When、Then中的Then）

针对刚开始试行此方案的团队，建议收集一些数据以验证此方案带来的改变，这些数据可以是下面这些：

1. 拦截的问题个数，收集持续集成的和平时开发中用例拦截的问题
2. 用例个数，测试人员完成的用例个数
3. 增加的用例数量，相对于传统的方式，这种方式增加了多少用例

整个流程中大方向上可能存在的挑战：

1. 对于行为的粒度划分
2. 用例实现与开发语言一致，导致测试人员的用例实现技能迁移性成本高
3. 开发人员和测试人员的协作能力