我们的目标
目标
引入 BDD 和 cucumber 是希望用 BDD 的方式来解决产品开发测试中的一些问题，主要是打通各个环节：
需求
需求通常由产品人员提出。
功能
每个需求展开为若干个功能/feature。
从产品人员的角度，表明为了满足该需求，需要实现这些功能。
从开发人员的角度，表明只要实现了这些功能，则视为已经满足该需求。
可以将
功能视为产品人员和开发人员针对需求达成的共识或者说契约。从需求到功能的展开，由开发人员主导，产品人员review，测试人员可以参与（强烈建议参与）。
测试点
每个功能展开为若干个测试点 / test point。
从测试人员的角度，表明为了验证该功能可以工作，需要通过这些测试点的检验。
从开发人员的角度，表明只要通过了这些测试点的检验，则视为功能已经实现。
可以将
测试点视为测试人员和开发人员针对如何做功能测试达成的共识或者说契约。从功能到测试点的展开，由测试人员主导，开发人员提供必要的案例补充，并做review，建议产品人员适当review。
测试点是可读性的文本描述，不是代码，不涉及到具体编程语言。
测试案例
每个测试点对应到一个测试案例。
每个测试案例都明确描述具体的输入，操作行为，和期待的输出（包括错误和异常）。
测试案例是可执行的代码，实现的是从可读性的文本描述到编程代码的转换。
测试代码
测试代码是测试案例中真正执行具体测试功能的代码，需要和被测试对象进行实际交互。
对应关系
在cucumber中,有以下对应关系：
- Feature 对应于 功能
- Scenario/场景 对应于 测试点
- step class 对应于测试案例
- 场景中的每个Step 对应于 测试案例的输入/输出等，同时映射到测试案例中的step方法
- step方法中的具体代码实现 对应于 测试代码