#1 楼
正如ByteBuster指出的那样，用户故事是对演员或客户希望通过产品实现的目标的非常高级别的描述，但并未详细说明该目标将如何实现。开发人员经常将用户故事分解为针对该目标的离散开发任务。开发人员还应该针对这些任务编写单元测试。
测试人员测试用户故事的目的是让自己陷入演员或个人的脚下，并思考角色可能采用的不同方式（测试）实现用户故事的目的。另外，请考虑一路上可能出错的事情，或可能阻碍实现用户故事目标的其他操作或流程。大块。尽管测试人员还经常测试软件的离散功能属性，但测试人员的主要职责之一是更全面地研究软件并从客户的角度进行测试。
评论
谢谢，我承认我对软件测试和敏捷测试领域还不是很陌生，所以这仅意味着我将研究已编写的故事并确定该故事是否可测试，并集思广益，探讨可能源自该故事的场景。 ？
–sam2013
13年7月21日在7:09
@ sam2013几乎可以总结一下，是的。
–凯特·保罗（Kate Paulk）
13年7月24日在12:08
#2 楼
正如其他答案所说，您可能不会直接测试用户案例。我过去使用的方法是这样的：每个用户故事都会有一个或多个验收测试。这些
测试通常涵盖高级测试场景（例如“鉴于
我已作为客户登录，然后单击链接“我的订单”
将我带到显示所有内容的页面该客户的订单。”-确切的
措辞可能有所不同）
每个验收测试通常可以分解为一个或多个测试用例。上面的示例可以被认为具有三个钢制
螺纹测试用例（假设客户登录名已经存在
功能）：
登录后，存在“我的订单”链接。
单击链接“我的订单”会转到指定的订单列表页面
订单列表页面上的订单与数据源中的客户订单完全匹配。
验收测试可能应该来自产品负责人，但您可以自行定义（在这种情况下，有助于进行
，如果可以的话，请联系产品所有者。）在测试用户故事时，我个人更喜欢保留接受测试，直到执行完与用户故事中创建的任务相关的所有测试之后-这些任务往往会比接受测试更细粒度和更低级别，例如（使用上面的示例）：“创建存储过程以从客户ID检索客户订单”
默认情况下，验收测试是钢线的一部分（也称为“快乐之路”-绝对的核心功能，没有它，故事将无法完成）。验证验收测试所需功能正确功能的测试也是钢丝。处理错误条件的测试可能不是钢螺纹，而边缘条件的测试则可能不是。通常，请保存所有不是钢螺纹的测试，直到所有钢螺纹测试都通过。
我的喜好是，直到所有测试通过或非-通过测试已被积压在另一个Sprint上，或者认为超出范围-也就是说，每个测试都已被考虑并且每个任务都已经过测试。但这是一个不错的起点。祝你好运。
评论
我知道已经有一段时间了，但是这个答案难道没有走一步吗？如果没有接受标准，则无法进行接受测试，因为那里有接受测试来验证是否满足接受标准。这些标准通常应由产品所有者定义，但实际上，通常由测试人员与产品所有者合作定义。定义了接受标准后，您可以选择是否自动执行它们。也许我只是习惯了另一种方法？
– Cronax
17年9月25日在12:34
在我的工作场所中，验收测试通常是验收标准：“已登录的客户可以单击“我的订单”，然后查看系统中所有订单的列表”在功能上与我的给定/何时/然后声明相同例子和我工作的地方是一样的。
–凯特·保罗（Kate Paulk）
17年9月25日在12:39
#3 楼
用户故事是软件开发生命周期中最高级别的需求工件。这里有一些用户故事的示例：
作为应用程序用户，尝试保存该文档，如果想要的文档名称已经存在，我希望看到一条警告；该警告应允许我选择是否覆盖现有的警告；
作为网站管理员打开网站，我希望看到一个仪表板，其中包含最重要的管理任务；
作为用户提交文档到远程系统，我想知道网络错误并让我们将文档保存在本地；如您所见，用户故事的性质非常广泛。通常，最高级别意味着最低的细节，最小的结构，因此，不同的人可能会不同地解释它们。这就是为什么
通常，质量检查通常不会直接测试用户故事。
相反，大多数问题跟踪工具都允许管理用户故事到各个开发任务的映射。 >查看此幻灯片以获取更深入的理论见解。此StackOverflow问题及其答案对主题以及如何使用JIRA进行此类映射的方式都有一些好处。
任务正在执行中，并且已由质量检查人员进行了测试，您可能对常规过程相当熟悉。
一旦绑定到某个用户故事的所有任务都看似已完成，质量检查就会将用户故事也标记为完成。
我应该做一个重要的说明。我见过一些确实对用户故事进行直接测试的团队。他们为每个单独的用户案例分配特定的成功标准，就像@Pangea的答案一样。这是你的选择;也许您应该考虑项目和开发团队的规模，也许还要考虑一些其他标准，以确定您是否真的需要直接测试用户故事。
评论
什么是“ QS测试仪”？可能是质量检查人员，有错字。具有讽刺意味的是。
查找首字母缩写词：BDD（行为驱动开发）。它基于故事。