1. 什么是用户故事？

用户故事描述了对用户、系统或软件购买者有价值的功能。由以下三方面组成：

卡片包含故事的文字描述，然而需求细节要在“对话”中获得，并在“确认”部分得以记录。

用户故事的优势：
强调对话交流而不是书面沟通
可以同时被测试和开发人员理解
大小适合做计划
适用于迭代开发
鼓励推迟考虑细节，直到你非常清楚的了解自己的真实需求

2. 用户故事怎么写？

用户故事，书写格式：
as …, i want …. ,so that……
作为{角色}，我想要{功能}，这样{（达到）目的}

遵循Invest原则：（注意：有先后顺序，优先级依次减弱）

Valuable 有价值 对用户或客户有价值
Testable 可测试 成功通过测试可以证明开发人员正确地实现了故事。也需要考虑自动化测试，只要有可能，就要把测试自动化
Scalable（Small/Sized）大小合适 根据团队、其容量及使用的技术来确定故事大小，保证能与用户沟通获得反馈，团队合理分工避免不必要的浪费
Independent 独立性 优先级会影响故事的解决顺序，故事间的依赖使估算变得困难
Negotiable 可协商 故事卡的作用是提醒客户团队和开发团队在以后进行相关需求的对话，它并不是具体的需求本身，无需包含过多细节（适当注释即可）。在能确定价值的情况下，实现方法如UI设计、技术方案等都是可协商
Estimable 可估算 能估算故事的大小（工作时间量）对开发甚至项目进度很重要

验收标准用来验证实现的用户故事是否符合客户团队的期望。同时，方便各方（需求方、产品、开发、设计、测试等）反复就细节讨论，提升产品质量和团队工作效率

Gievn-When-Then 书写格式：
Given (在什么样的情景或条件下)
W︎hen (做了什么操作, 采取了什么行动)
T︎hen (得到了什么结果)

非功能性需求的分类：

非功能性需求如何写：
可直接使用“作为…，我想要…，这样…“模版
可直接使用“Gievn-When-Then ”格式，转换为验收标准

一个用户故事具有独立性，可以安排在当前或下个冲刺被开发；验收标准如果有缺失，可能会导致用户故事不能上线。

（至于什么是测试用例，这里不再赘述）按照覆盖范围大小：测试用例>验收测试>验收标准

结合自己所在的项目，一种测试参考文档书写的思路为：运用用户故事和验收标准模版，再根据具体的业务场景，给相应的验收标准加上详细的说明或者测试用例，测试人员可以按照这样的标准化的文档去测试。

参考：