用户故事 | 验收标准

定义

验收标准就是一系列可以接受的验收条件或者业务规则，且与功能或feature相互匹配和满足，同时也能被产品负责人和相关人接受。

如何书写

验收条件可作为验收测试用例的具体例子。这也是我们常说的实例化需求，也是为了避免误读，让抽象的需求变得具体和可测试。

这一步很难，但非常重要。没有明确的验收条件，我们便不知道如何测试，业务也不知道如何验收。

通常，一个用户故事包含若干个验收条件，包括快乐路径（Happy Path）与意外场景（Exceptional Scenario）。

下面我将以一个具体例子来说明什么是含具体例子的验收条件和实例化需求。

假设我要开发一个基金交易系统，其中一个用户故事是“当投资者申购基金后，他/她将在T+2收到交易确认短信，期间如果遇到周末或假期将顺延”（T是交易日的意思，T+2即两个交易日后）。

这个用户故事看似简单，但其实隐藏着不同的场景。我们可以通过一些实例来具体说明，构成其验收条件：

快乐路径

实例1：成功申购，没有假期顺延情况 假设投资者张三（男）在2017年9月25日申购了沪深300指数基金1000元，当天该基金单位净值为2.5000，申购费率是1.5%；
当申购成功后；

那么他在2017年9月27日收到短信，内容为“张三先生，您于2017年9月25日申购了沪深300指数基金1000元，单位净值为2.5000，份额为394份，交易成功，份额已登记于您名下”。

实例2：成功申购，有假期顺延情况 假设投资者张三（男）在2017年9月29日申购了沪深300指数基金1000元，当天该基金单位净值为2.5000，申购费率是1.5%；
当申购成功后；

那么他在2017年10月10日收到短信，内容为“张三先生，您于2017年9月29日申购了沪深300指数基金1000元，单位净值为2.5000，份额为394份，交易成功，份额已登记于您名下。”

（因为2017年9月30日至2017年10月8日为假期，即非交易日，交易确认顺延）

实例3：成功申购，在假期内申购 假设投资者张三（男）在2017年10月5日申购了沪深300指数基金1000元，当天该基金单位净值为2.5000，申购费率是1.5%；
当申购成功后；

那么他在2017年10月11日收到短信，内容为“张三先生，您于2017年10月9日申购了沪深300指数基金1000元，单位净值为2.5000，份额为394份，交易成功，份额已登记于您名下。”

（因为2017年9月30日至2017年10月8日为假期，即非交易日，假期内的申购日将顺延到假期后第一个交易日）

意外场景

实例4：申购失败 假设投资者李四（女）在2017年9月11日申购了沪深300指数基金1000元，当天该基金不可申购；
当交易确认后；

那么她在2017年9月13日收到短信，内容为“李四小姐，您于2017年9月11日申购了沪深300指数基金1000元，由于当天本基金不可申购，交易失败，申购款1000元将在2个交易日后全款退还到您申购的银行卡。”

意外场景的情况可能比较多，比如网络问题导致的意外等。像这种情况我们实际操作时一般都是放在测试用例里面，而不是验收标准里。所以开发人员在开发时要同时参考验收标准和测试用例。

书写格式

通过上面的例子，可以看出验收条件都是按照“Given…When…Then”的格式书写的，也叫 Gherkin 语言格式。这种语言格式可以让开发人员更好的了解验收条件所要表达的内容。就像用户故事的书写格式一样，可以让开发人员更充分的了解用户故事所传达的需求内容。关于用户故事的书写格式优势，大家可以参考这边文章：为什么要标准化用户故事格式。