问如何编写好的测试场景？

EN

为了提高测试场景的质量，您可以遵循以下建议：

1. 使用清晰简洁的语言:用简单的语言编写场景，让涉众(包括开发人员、经理和最终用户)很容易理解。
2. 指定目标和上下文:明确说明方案的目标和测试环境。
3. 定义预期结果:明确定义方案的预期结果应该是什么。
4. 包括预条件:指定在执行方案之前需要满足的任何预条件。
5. 使用示例:使用具体示例来说明场景并使其更容易理解。
6. 使用一致的格式:对所有测试场景使用一致的格式，使它们更容易阅读和理解。
7. 获取反馈:与其他涉众共享您的测试场景，并获得反馈以进一步改进它们。
8. 确保方案是可测试的。应该清楚需要采取哪些行动，以及预期的结果是什么。
9. 包括相关的上下文和背景信息，以提供对方案的明确理解。
10. 考虑不同的用户透视图，例如客户、管理员或开发人员，并编写测试不同用例的场景。
11. 根据它们给系统带来的风险或它们对涉众的重要性，对您的方案进行优先排序。
12. 定期回顾你的场景，并在必要的时候更新它们，以确保它们保持相关和最新。
13. 最后，确保所有团队成员都易于理解和使用这些场景，包括那些可能不太熟悉所测试的系统的人员。

下面是一个例子：

情景: IVR援助中宠物主人信息的验证

目的:验证IVR系统根据PMS数据库中的注册电话号码正确识别宠物主人，并在数据库中发现该号码时不询问其姓名。

步骤

1. 宠物主人发起对IVR系统的呼叫，并提供他们的电话号码。
2. IVR系统将提供的号码与PMS数据库相匹配。
3. 如果在PMS数据库中找到电话号码，IVR系统将跳过询问宠物主人的姓名。
4. 如果在PMS数据库中找不到电话号码，IVR系统将提示宠物主人输入他们的名字。

预期结果: IVR系统只应询问宠物主人的姓名，如果在PMS数据库中找不到他们的电话号码。如果找到电话号码，IVR系统不应询问宠物主人的姓名。

您的场景和描述对我来说不是一个测试场景，而是一个功能描述。一个很难读懂的东西，它会做出假设，而且缺乏直率诚实的注意力。

我会用作为一个。我想。所以...用户故事格式重写它：

user Story 002: Automaticaly将PMS系统中的宠物所有者名称与IVR辅助程序的用户Jack (某些角色)匹配，如果可用的话，我希望预先填充宠物所有者的名称(功能功能)，这样我就可以快速处理电话呼叫，而不需要不必要的中断(值)接受标准：

• IVR使用PMS数据库字段<Pet Owner number register>进行号码匹配。
• 如果号码不匹配，询问宠物主人的名称，如用户故事001中所述。

人物角色<some role>可能不是管理员，管理员维护系统，可能他并不真正关心它是如何工作的。也许是兽医杰克？我不知道你的域名，但我怀疑正确的角色是管理员。此外，我喜欢使用一个真正的人的名字，做这个动作或使用该功能。

特征是一种你想要发生的行为，你描述的是没有发生的事情。这就为解释所发生的事情留下了空间。

不描述角色值的值。

该特性的测试场景可以是：

• 正确匹配和显示宠物主人的名称。
• 宠物主人的名字不匹配，并被询问。
• 当PMS系统关闭时，询问宠物主人的名称。
• 等等..。

也许用那是什么时候场景风格编写它们：

Scenario: name is matched and displayed correctly
  Given the pet owner name is in the PMS system
  When I open the screen for pet "Jack Russel"
  Then then the pet owner name is "Saskia"

我喜欢用户故事、验收标准和GivenWhenThen场景的组合，因为它让我们的团队思考、交流和共享需求和测试案例。

编写涵盖所有场景的良好和有效的测试用例描述qa服务公司的效率。

下面的步骤也可以是有益于涵盖测试场景的步骤。

• 如果向用户故事提供了上述验收标准，那么可以创建涵盖这些场景的直接测试用例。
• 在前面的步骤之后，可以创建更多的消极和积极的用例，使它们成为回归测试周期的一部分，以确保涵盖所有场景。
• 可以创建烟雾和正常测试用例，以确保最重要的功能正常工作，并且它们可以按预期工作。
• 可以为每个模块分别创建单元测试用例，深入讨论它们。
• 一旦创建了单元测试用例，就可以创建涵盖不同模块的集成场景的测试用例。