编写业务测试人员看得懂的测试用例

为什么业务测试人员需要不一样的测试用例

系统测试由构建系统或熟悉系统的人来做。用户验收测试则由使用系统的人来做：他们了解业务工作，而不了解配置。他们不知道哪个字段是新的、哪个流程在后台运行，也不知道开发人员的本意。

因此，UAT 测试用例必须适合这样的人：

• 对业务流程了如指掌，但不熟悉新界面；
• 在其他工作之间只有几个小时，而不是一周；
• 永远不应该去猜某个步骤是通过还是失败；
• 遇到不清楚的步骤会停下来等待，浪费时间。

在编写清晰的测试用例上每花一小时，就能在测试日节省许多小时：更少的提问、更少最终被证明是误解的问题，以及在 go/no-go 时值得信赖的结果。

从用户故事和流程出发

测试用例有两个来源，两者缺一不可。

用户故事及其验收标准

用户故事说明某人想做什么以及为什么：作为销售代表，我希望转换一个合格的潜在客户，以便获得一个客户、一个联系人和一个商机。它的验收标准说明什么时候算完成。每条验收标准都可以成为一个步骤或一个测试用例。

检查覆盖率：范围内的每个用户故事都至少需要一个测试用例。没有测试用例的用户故事就是一个缺口，而缺口会在生产环境中暴露出来。

端到端的业务流程

用户故事是为开发人员切分得很小的。业务则按跨越多个用户故事的流程工作：从潜在客户到回款、从报价到订单、从邮件到解决的个案管理。一个用户故事单独来看可能通过，而流程却在两个团队交接时断掉。

因此，要增加端到端的测试用例，跨角色地从头到尾跟踪一个流程：销售代表制作报价，经理审批，订单转到财务。这些往往是对业务方最重要的测试用例。

在 UAT Studio 中在 User stories 卡片上读取来自 Jira 或 Azure DevOps 的用户故事，并勾选 Only stories without test cases 查看缺口。使用 AI test design 模块时，AI 会根据您的用户故事或流程描述建议测试用例，也可以使用贵公司自己的模型。在您批准之前，任何内容都不会成为测试用例。没有该模块时，Prepare with your own AI 会提供一段提示词，供您粘贴到贵公司的 AI 中；标记为 [CHECK] 的步骤是需要核实的假设。

每个测试用例一个目标

一个测试用例测试一个业务场景，只有一个目标。它的标题用业务的语言说明测试人员要完成什么：

• 转换一个已有客户的潜在客户
• 审批折扣超过 20% 的报价
• 将来自已知客户的邮件路由到正确的队列

不要写成测试潜在客户对象，也不要写成潜在客户、商机和报价。当一个测试用例有多个目标时，一处失败会阻塞所有目标，而结果也说明不了什么：哪里失败了，哪些仍然可用？

一个测试用例应该多大？

一般来说，一个测试用例有三到十五个步骤，测试人员需要五到二十分钟。明显更长的，可能包含不止一个目标：拆分它。明显更短的，可能应该与相邻的测试用例合并。

端到端测试用例是例外。它们跟踪整个流程，可以更长。保留它们，但要确保流程的每个部分也有自己较短的测试用例，这样出现失败时很容易定位。

带预期结果的步骤

每个步骤都有两部分：操作（测试人员做什么）和预期结果（应该发生什么）。预期结果让步骤变得可测试。没有它，就由测试人员自己决定什么算够好，而两位测试人员的决定会不一样。

编写操作

• 每个步骤一个操作。打开潜在客户并点击 Convert 是可以的；一个步骤里点五次就不行。
• 以动词开头：打开、点击、填写、选择、保存。
• 使用界面上显示的标签，用粗体或引号标出。
• 说明做什么，而不是系统内部如何运作。写保存报价，而不是触发审批流程。

编写预期结果

• 说明测试人员看到什么：一条消息、某个字段中的值、一条新记录、一个状态。
• 要具体。写商机处于 Qualification 阶段，而不是能用。
• 在重要时写明不应发生什么：不会创建第二个客户。
• 对于系统自动完成的事情，说明去哪里查看：个案在一分钟内出现在 Benelux Support 队列中。

测试数据和角色

测试数据

在 UAT 中，测试人员花在找数据上的时间比任何其他环节都多。凡是重要的地方，都把数据写进测试用例：哪个客户、哪个产品、哪个价目表或价格手册、多少金额。在第一个测试日之前，在测试环境中准备好这些数据。

• 使用明显是测试数据的名称，例如 Jansen Logistics (test)。
• 当测试人员要修改数据时，给每人分配各自的记录，以免两个人编辑同一个商机。
• 加入边界值：略低于和略高于上限的折扣、一个空着的必填字段。
• 能避免的地方，不要使用客户的真实个人数据。

角色

在 CRM 中，用户能看到和能做什么取决于他们的角色：在 Salesforce 中是简档和权限集，在 Dynamics 365 中是安全角色和业务部门。UAT 要证明每个角色都能完成自己的工作，且只能完成自己的工作。因此，每个测试用例都要说明由哪个角色测试，测试人员使用恰好拥有该角色的测试用户登录。

绝不要用管理员来测试。管理员可以看到并操作一切，这样 UAT 本应发现的问题就会被掩盖。

在 UAT Studio 中每个步骤都有操作、预期结果，以及可选的测试数据。每位测试人员都有一个 Test role 和一个 Test account，在其测试顶部显示为 Log in as …，并且在他们记录的每个问题上，姓名旁都会显示该角色。

优先级和风险

永远没有足够的时间把所有内容都测得同样好。为每个测试用例做标记，让重要的测试先进行，并且即使时间不够也能完成。

在旁边加上风险：上线后出错的代价是什么。发票上的价格错误属于高风险；报表上的标签错误属于低风险。在同一优先级内，测试人员先从高风险开始。

对 Must 要严格。如果一半的测试用例都是 Must，这个标签就失去了意义：只把它留给业务方离不开的内容。与流程负责人商定优先级：他们也会在 go/no-go 时做决定，而未通过的 Must 测试用例在那时最为关键。

在 UAT Studio 中在编辑器中或导入时的某一列中设置 Priority（Must、Should、Could）和 Risk（High、Medium、Low）。其他工具的值也能识别：Critical 和 High 变为 Must，Medium 和 Normal 变为 Should，Low 变为 Could。测试人员会先看到他们的 Must 测试用例，并在每个优先级内先看到高风险的测试用例。

示例

测试用例 12：审批折扣超过 20% 的报价

优先级 Must，风险 High。用户故事 CRM-118。角色：销售代表（步骤 1 至 3）和销售经理（步骤 4 和 5）。

注意它为什么有效：标题中只有一个目标，每个步骤一个操作，预期结果可供测试人员核对，写明了数据和角色，并在步骤 3 中包含一条异常路径。再为低于上限的折扣添加第二个测试用例，这种情况应该无需审批。

常见错误

• 没有预期结果，或者写按预期工作。测试人员只能去猜预期是什么。
• 技术语言。数据库中的字段名、对象名，或者检查触发器是否触发。请使用界面上的用词。
• 一个测试用例目标太多。一处失败会阻塞其余部分，结果也说明不了什么。
• 只有正常路径。加入必填字段留空、超过上限的值、不应看到某条记录的用户。
• 缺少测试数据。打开一个商机：哪一个？处于哪个阶段，带哪些产品？
• 没有角色。测试人员用手头的任何账户，往往是权限过多的账户。
• 照搬系统测试。为开发人员编写，业务测试人员无法照着执行。
• 全都是 Must。那就等于都不是，重要的测试也无法优先完成。
• 写完一次，无人阅读。在测试日之前没人检查过的脚本，满是过时的标签和错误的菜单。

请关键用户审核

在测试日之前，请业务部门的一名关键用户阅读测试用例，并在测试环境中试做其中两三个。他们会发现编写者看不到的问题：某个步骤默认了某些知识、某个标签已经改变、某个流程在另一个国家的运行方式不同。

同时检查范围内的每个用户故事都有测试用例、范围内的每个角色都有要测试的内容，以及测试数据确实存在。上线后保留这些测试用例：它们就是您下一次 CRM 版本发布的回归测试。

在 UAT Studio 中从 Excel、Azure DevOps、带 Xray 或 Zephyr Scale 的 Jira 或 TestRail 导入测试用例，或在编辑器中编写。模板库是每个付费套餐的附加组件，提供适用于 Salesforce 和 Dynamics 365 的现成脚本，可按您自己的配置进行修改。

免费使用

关于 UAT 之前、期间和之后需要安排的其他所有事项，请参阅 CRM 上线 UAT 检查清单，同样提供免费 Excel 文件。