什么是用户故事(user story)
用户故事就是从用户的角度来描述通过做什么操作，达到什么样的价值，如作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
关于用户故事，Ron Jeffries用3个C来描述它：
卡片（Card） - 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。确认（Confirmation）- 通过验收测试确认用户故事被正确完成。Story分析的格式
格式其实不重要，关键是内容，但是为了方便阅读和学习，以及美观，还是需要整理一份项目组内认可的模板出来，后续成员都按照使用相同的模板输出材料。
User Story分析材料（下面简称Story分析材料）的读者，照我的理解，Story分析就是针对一个小特性的说明材料，辅助交流和记录问题与解答，大部分情况下它的读者比较单一，比如认领Story的开发人员和对应的测试人员，以及后续维护该特性的开发人员。假如需求前端人员的输出材料比较简单，Story的分析材料还担负起了与前端需求人员交流的作用，这时前端需求分析人员也会成为Story的读者。因此，Story分析材料的格式和内容需要依据用途来做一定的适配。
Story分析的内容
Story分析中常用的组成部分，比如应用场景，系统现状，功能设计，性能设计，外部依赖，外部接口等等，当然有时还需要根据项目特殊性增加一些标题，用以提醒团队成员做专门的分析。
Story分析怎么去做
这个其实不是问题，直白点讲，需求理解了，怎么想就怎么写。在我所在的团队，Story分析材料不限体裁，不限字数，不限文笔，只要思路清晰，把关键点描述到位，不影响项目组其他同事学习和交流，其它方面都不会太在意。但从项目实地运作的过程看，不少理科出身的程序员同事在写作Story分析时，经常出现思路不清晰、跳跃性强、关键点缺失或者特性分析不完整的问题，部分同事在修改几次之后仍然会有这样那样的问题。这说明平时缺少写作经验，不善于通过书面语言表达自己的想法，虽然可能对项目编码影响不大，但显而易见，对个人发展会很不利。
一个良好的User-story的编写应该遵循INVEST原则
Independent：独立性
用户故事之间应该具有独立性（有点类似于UT中的test case），不应该依赖于其他的用户故事。如果用户故事存在依赖性那么就会导致用户故事之间存在着不同的优先级，只有被依赖的用户故事完成才能继续开发依赖的用户故事。一般可以通过组合用户故事或者分割用户故事来减少用户故事间的相互依赖性。
Negotiable：可协商
用户故事不是签订的商业合同contracts，它是由客户或者PO同开发小组的成员共同协商制定的，如果最开始像商业合同一样设定了太多的条条框框和限制就无法更好的沟通及协商，也就不可能划分出既让客户满意，也能让开发认同的好的用户故事。
Valuable：有价值
用户故事必须对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。
Estimable：可评估
对于一个用户故事的划分需要足够的领域知识，使得在划分i故事之时就能大致了解故事开发的周期，为了减少估算的不确定性，故事本身不能太大。
Small：短小
故事应该尽量的短小，当然也不是说越小越好。短小的故事可以减少划分过程中估算的误差，最好的故事是能够在一个迭代周期之内完成的。如果太大就应该考虑将其拆分为多个粒度更小的用户故事。
Testable：可测试
个人认为这一点在所有的特性中对于用户故事的重要程度最高。如果一个用户故事无法进行测试，那么也就无法判断该故事是否完成，是否可用。除此之外，对应的验收测试也最好是自动运行的，这样在任何时候都能触发该用户故事的检验。最后，必须在定义了验收测试通过的标准后才能认为故事划分完毕。
关于Testable，有一个较为经典的例子：
As a user, I want to be able to cancel a reservation so that I can get a refund for the trip not taken.
作为用户，我希望能够取消预订，以便我可以获得未参加旅行的退款。
关于此用户故事前面所提到的几个要素who，what，why都满足，那么验收测试应该如何去做？模拟的应该是实际的真正场景，如：退款是全退还是部分退还；提前多久cancel才是有效的；退还款项如何与用户之间进行确认等等。
按照刚才的假设，做一个真实场景的验收测试用例，通过Given-When-Then的方式来设定：
Given：“我”付款1000RMB预定了一个3周后从成都飞往三亚的航班。
When：在航班起飞前一周“我”取消了该行程。
Then：“我”应该得到预定机票半价的退款（500RMB）
在对用户故事设定验收测试的条件时候，分别对应：starting state—》event—》final state
任何的user story，在验收测试的时候都必须至少设定一个defaule scenario。
如何编写用户故事验收测试
首先来说一下个人对于测试类型的几个理解吧，如果要保证一个软件产品可以被正常使用，如下几个测试是少不了的：
在编写测试过程中，对于测试如何写，写多少用例算是足够的，不同的人有不同的理解，根据《用户故事》介绍的内容和自己的一些理解，整理如下：
关于测试用例的责任主体可以分为两个，一个是客户团队，一个开发团队
客户团队掌握需求，需要定义可交付的测试用例的编写。此时的测试用例既是需求的验收标准，也是对需求的进一步解释澄清。开发团队可以通过对于用例的阅读，进一步的明确客户的实际需求，也就不至于做成的产品和客户的期望有偏差。
比如用户期望做一个招聘网站中供HR输入招聘信息的页面，客户期望可以录入的信息包括岗位名称，工作地址，薪资范围等等，求职者可以查看这些信息。 对于开发人员来说，会把所有的信息录入到界面中进行展示，很有可能要求每个信息都是必填的。但客户的实际希望是某些信息（比如薪资范围）是可以不录入的，对于不录入的条目，对于求职者也是不需要展示的。 像这样的信息，如果通过测试用例的方式明确标记出来，会极大的减少后期返工的成本。
客户团队的测试用例一定要在开发之前写，可以由客户团队来完成或者客户团队和开发团队共同完成，在开发之前就完成测试用例的做法，也就是TDD所要求的工作方法。开发团队需要完成什么样的测试呢？
开发团队更多的关注于功能的实现方法，理所当然的就是单元测试的编写了。关于单元测试是在开发之前写还是开发之后写，我个人的看法是需要分两半，一半在开发之前写，一半在开发之后写。
开发之前写的内容是把客户团队提供的测试用例转换为可执行的单元测试代码，可以在此基础上再增加一些设计方案中涉及到的细节的描写（需求在转换为设计方案的过程中，会有一些更加细化的内容，这些内容对客户来说可以认为是透明的）。开发之后写的内容是把在具体编码过程中涉及到一些内部逻辑的判断进行一些边界测试或者健壮性测试，避免出现空指针异常等一些低级的错误。