实例化需求

Trainning

实例化需求的方式既能清晰地表述需求，消除客户、需求分析师、开发人员与测试人员在沟通中可能产生的理解分歧；又极为融洽地支持开发人员进行有效地测试驱动，帮助测试人员条理清晰地完成对需求功能的验收和测试。

a.定义

一段很好的需求说明，加上实例（场景+数据），实际上就是她所描述的功能的验收测试
满足：

a.精确、可测
b.是真正的需求说明，而不是脚本
c.是关于业务功能的，而不是关于软件设计的

b.实例化

• GIVEN从句描述的是场景的前提条件、初始状态，通常是一种现在完成时态；
• WHEN从句是采取某个动作或者是发生某个事件，一定是动词，通常是一般现在时；
• THEN从句用“应该…(should be…)”来描述一种期望的结果，而不用断言（assert），后者与测试关联更紧密。

c.方法

由Gojko Adzic的著作Specification By Example（实例化需求），介绍了如何通过实例去分析和沟通需求。它是一组过程模式，可以协助软件产品的变更，确保有效地交付正确的产品。实例化需求的过程分为：

• 从目标中获取范围
• 用实例进行描述
• 精炼需求说明
• 自动化验证，无须改变需求说明
• 频繁验证
• 演进出一个文档系统
  更多内容，请参考该书。

注意：单元测试不能针对方法编写测试，而应根据业务编写测试用例。一个测试方法只能做一件事情，代表一个测试样本和一个业务规则。

d. TDD的驱动力

设计接口是体现测试驱动开发“驱动力”的重要一点。之所以先编写测试，就是希望开发人员站在调用者和业务价值的角度去思考，即所谓“意图导向编程”。从调用的角度思考，可以驱动我们思考并达到如下目的：

• 如何命名被测试类以及方法，才能更好地表达设计者的意图，使得测试具有更好的可读性；
• 被测对象的创建必须简单，这样才符合测试哲学，从而使得设计具有良好的可测试性；
• 测试使我们只关注接口，而非实现；

以下内容毕业生培训不讲

d.BDD

• 1. 关注的是业务领域，而不是技术：BDD强调用领域特定语言（DSL, domain specific language）描述用户行为，定义业务需求，而不会关心系统的技术实现。
• 2.不是工具，强调的是一种协作方式：BDD要求各个角色共同参与系统行为的挖掘和定义，以实现对业务价值的一致理解。
• 3.不是关于测试的：BDD源自TDD,但重点不是关于测试，所强调的沟通与协作可以指导更好的做自动化测试。
• 4.全栈敏捷方法：BDD促使团队所有角色从需求到最后的测试验证，进行高度的协作和沟通，以交付最有价值的功能。

e.BDD怎么做？

用例场景的描述格式“GIVEN… WHEN… THEN… ”对大家都不陌生，但用这个格式写出好的用例却是非常的难，尤其是新手。这里总结几点供大家参考：

• 1.业务层抽取，业务语言描述
• 2.技术人员可懂，自动化友好
• 3.数据驱动，需求实例化

f.Example:

场景一：检查收件箱，可以看出第三个清晰明了且能体现业务价值，比较符合上面的要求。

Scenario: Check Inbox
  Given a user "Tom" with password "123"
  And a user "Jerry" with password "abc"
  And an email to "Tom" from "Jerry"
  When I sign in as "Tom" with password "123"
  Then I should see one email from "Jerry" in my inbox

Scenario: Check Inbox
  Given a user "Tom"
  And a user "Jerry"
  And an email to "Tom" from "Jerry"
  When I sign in as "Tom"
  Then I should see one email from "Jerry" in my inbox

Scenario: Check Inbox
  Given I have received an email from "Jerry"
  When I sign in
  Then I should see one email from "Jerry" in my inbox