这是鼎叔的第六十六篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本专栏和微信公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。

用户故事的概念于 1998 年被正式提出，在 2001 年开始逐步成熟。目前，市面上有关讲解用户故事方法的著作不少，在 Scrum 流程中配合使用，效果显著。我们先回顾一下用户故事最核心的知识内容。

用户故事核心知识

用户故事用来描述对用户有价值的特性或功能，相对于传统的需求规格说明书，它用简化的形式促进团队交流，降低修改的成本，能灵活的调整以响应变化。通过用户故事的验收标准驱动，让所有敏捷团队成员和干系人，对最终目标达成共识。

用户故事的描述格式通常为：As（特定的用户），I want（具体场景下实现的某个功能），So that（获得某种目的/价值）。

用户故事要符合 3C 原则：Card（卡片，上面是一句话概述，能让成员快速识别），Conversation（通过产品和技术的直接对话，了解背后的需求细节），Confirmation（验收条件- AC：Acceptance Criteria，确保清晰无歧义）。通常我们可以在一张 Card 的正面写上用户故事的描述，背面写上测试如何验收，因为空间有限，验收描述必须非常简洁。

用户故事也要符合 INVEST 原则：Independent（彼此独立，相互间松散耦合，尽量减少依赖），Negotiable（用户故事可以协商，不是一成不变的，需要 PO 和成员以及客户的坦诚交流）， Valuable（能体现对客户的明确价值），Estimable（能够被开发团队合理估算的）， Size Appropriately（大小合适，能够在迭代中完成，如果偏大需要拆解用户故事），Testable（故事有明确无歧义的验收条件，能被明确客观的测试用例验证）。

用户故事鼓励推迟细节考虑，因此在进行讨论时不要过早涉及用户界面，也不用给用户故事卡片编号。

推荐学习书目：Mike Cohn 的《用户故事与敏捷方法》。

测试启发

一、所有用户故事的验收标准是否明确，团队是否对验收测试用例达成一致？

验收标准通常写成 GWT 的格式：

Given（什么场景或条件下，如在首页新闻的搜索框）

When（采取了什么行动，如输入了品牌关键词）

Then（得到了什么结果，如输出了该品牌直接相关的热门新闻，可以浏览点击）

示例：

验收标准可以避免团队成员对需求理解的偏差，帮助测试人员快速掌握测试范围。但验收标准不是验收测试，验收标准定义了用户故事完成的标准，验收测试要基于验收标准，但是验证的具体场景更广，建议每个用户故事验收的测试用例不超过 6 个（通常是 1-6 个之间）。

特性团队对具体的验收测试用例达成一致，最大程度上保障开发人员能更好地进行验收测试驱动开发，交付的初版质量也会更高，更容易一次性通过验收。甚至在整个迭代的活动中，验收测试用例都可以作为团队统一的沟通语言，降低不同角色对需求理解的不一致性。

注意：验收测试用例不等于完整的测试设计用例，它通常仅仅只是完整用例集的子集，优先级很高。

二、所有用户故事是否具备可测性。

我们是否能明确测试它们的工具方法，判断测试通过的指标，如有疑问，需要在评审中和文档中获得澄清。

特别小心需求描述中不清晰的定义，比如性能要增加 50%（具体什么场景，什么指标？），安全性要提升（具体哪一项产品规格的安全性，要通过什么工具的安全检查？）。

三、用户故事估算排期，必须考虑测试完成任务的耗时。

用户故事在迭代中达到 “完成” 的定义，通常是包含 “相应测试任务完成” 的。所以在估算时要纳入相应的开发自测和专业测试时间。

针对被拆解的用户故事，也需要我们在本迭代中对测试工作量做好评估。故事被拆解后，有利于测试工作量的评估更加精准。从故事验收及回归测试的经验来看，开发工作量在 2-3 人天的用户故事，其测试验收的效率是最高的，可以在收到版本的当天完成用例集测试反馈，便于开发快速修复问题。

如果评估出来的测试任务人手不足，需要采取一定的补救措施，如安排开发人员支持测试、降低非核心功能用例覆盖等。

针对客户端版本和重要服务的重构版本，正式发布的准备成本比较高，风险也比较高。我们通常会预留一个迭代做发布前的准备，包含缺陷修复和集中的系统测试投入，如兼容测试、回归测试和核心指标性能测试等。这个迭代就建议尽量不安排新功能的开发和测试了。

四、产品经理的需求文档是否支撑了各个用户故事需要的三要素信息？尤其是否说清楚了 - 对什么用户提供了什么价值？

我希望推动产品经理在需求文档中给出明确的用户价值描述，原先觉得这个要求是不是略高，但结合用户故事的核心知识，我认为这是非常有必要的基础要求，因为需求就是由一系列用户故事组成。既然能说清楚其单个故事的价值是什么，当然能进一步度量最终交付的效果并改进。

五、技术需求也应该拆解为技术故事。故事作为团队展开工作的基本单元，它不仅仅是功能描述，还可以是性能，安全，技术债务改造描述。举例如下：

图片

对于通用型的非功能需求，即适用于所有用户故事的质量标准，如性能指标不低于多少，合规不违反，不能有资金损失等，可以用相应的约束卡片来书写，让团队在迭代活动中能关注到，但约束卡片的故事点是 0。

测试技术故事也要能识别，合理排期。

测试技术故事通常是重要不紧急的事项，而且不太好通过用户视角来描述其价值和验收标准，因此很容易被 PO 和团队忽略。测试人员需要主动澄清这个故事对特性团队的长期收益。越早还债，收益越大。

比如，基本接口的自动化测试覆盖，引入更好的性能测试工具和漏洞扫描工具，给看板增加质量告警等。测试技术故事也需要每个迭代能看到具体的成果，避免团队对未来的故事排期失去耐心。

有同学可能会问，有些技术需求很难估算到底需要多少时间完成，怎么办？那我们就用探针法拆解它：当前这个迭代只安排该需求的调研分析（我们称之为探针需求），输出关键结论报告，例如技术背景、行业案例、建议的实现方案及其风险等。下个迭代再根据调研结论进行一定开发工作量的技术故事实现。

六 用户故事描述中的角色（As Who），团队可以为角色建模，从而避免用户故事的角色遗漏。

通常建模的流程是：集体脑爆出角色集合，用人物卡片的方式展现。在根据使用频率、使用水平、使用目的来区分典型人物，同时保留一定的极端人物（有利于发现更多体验风险）。根据最后精选出的代表人物创造虚拟身份信息和形象，这样可以提升生动性，让成员们有代入感。

七、鼓励客户参与用户故事及验收条件的编写，客户可以用更商业化的语言来描述。

技术人员很多时候是无法直接接触到用户的，那如何获取有用的需求信息呢？我们可以和下面这些角色合作获取信息，但是要小心不同角色出发点的局限性。

和客户销售人员合作。要注意销售人员会更关注收入和利润，对用户价值可能会短视。

和领域专家或分析师合作。专家角色会带来很多洞见，但也可能不接地气，忽视用户真实细节。

组建用户代表团。需要注意代表团成员的差异性，比如，是否兼顾收费和免费用户，是否充分包含了不同背景的用户，是否熟悉竞品等。

八、用户故事不是什么。

用户故事不是国际软件需求规范（IEEE830）,用户故事基于敏捷会严格控制成本。IEEE830 侧重于需求清单，而不是用户目标，每个需求成本是不可见的。

用户故事也不是记录系统需求的用例，用户故事比系统用例小，后者往往是完整需求中的多个场景的大而全描述。用户故事寿命短，不包括界面细节，更关注商业目标。用户故事更能传播隐形知识，但是在大型团队还需要把重要交流记录下来。

缺陷集合也可以当成一个用户故事。

九、用户故事和 XP/Scrum 的关系。

用户故事起源于 XP 实践，其方法体系非常契合 XP 的价值观。

用户故事方法和 Scrum 流程深度融合。比如我们在 scrum 站会中会同步上一天的故事进展。高层管理者可以参加站会，但是不能提问打乱。