完善的质量保证测试——用户流程教程

已发表: 2022-03-11

随着产品和服务的部署越来越快，质量保证 (QA) 必须适应不断变化的环境，有时在更短的时间内达到相同的覆盖水平。我们如何避免数量超过质量的错误？我们如何覆盖更多、提高效率并在工作中仍然有效？

我们都知道创建测试用例需要很长时间。我们必须应用不同的技术、测试类型，并记录前提条件、步骤和预期结果。此外，我们必须制定一个测试计划。

质量保证专家经常发现自己没有时间，尤其是当他们试图完成质量保证流程中的所有阶段时。最令人头疼的是测试计划和设计阶段，围绕测试用例创建和测试文档展开。完成所有工作可能需要几个小时，有时甚至是几天的努力，而且通常他们会选择跳过某些可交付成果并进行总结，而忽略可能导致测试被遗忘的重要信息。这也导致失去知识共享的好处。

传统 QA 测试符合用户流程

我是传统测试用例和测试计划的忠实粉丝。它们不仅有助于识别大量的测试用例，而且还能很好地记录产品。你可以在训练中使用它们，团队中的任何人都理解它们。您不必过分依赖经验让某人开始测试。测试计划包含更多信息，例如详细说明范围、测试项目、您正在测试的功能以及您不测试的功能。测试计划中还有一项风险分析。这些只是其中的一部分好处，但是在许多情况下，所需的总时间太长了。

测试计划的目的是项目利益相关者之间的一种沟通方式和协议。它有助于详细说明测试产品的目标、所需资源以及任何方法或策略。该计划有助于确保一切都在考虑之中，并使利益相关者对质量保证过程的战略投资充满信心。没有具体规定该计划必须为 10 页长。我们可以重新定义它以适应快节奏的团队。

另一种方法是简化传统的测试用例和测试计划，以减少所需的时间投资，但提供对所有利益相关者有意义的相同（如果不是更多）覆盖率和文档。这涉及一个单一的事实来源，一个扭曲的用户流。通过构建和维护用户流程，您将已经为您完成了大部分测试用例设计。这可以应用于任何产品或团队，并且在细节和结构方面是通用的。

使用流程方法将帮助您缩短测试文档的周转时间。这不仅适用于手动 QA，也适用于自动化。该流程还可以对测试计划的某些部分做出贡献。

顺其自然

事不宜迟，让我们直接开始为一个简单的消息传递网站构建用户流程。

我们首先需要一个免费的思维导图工具。我个人使用 XMind。随意下载您喜欢的任何工具——我们将只使用基本功能，例如绘制流程图、为某些主题添加“注释”、为不同的条件着色和使用标签。

我们的第一步是了解产品。通常，您将参考模型图像或线框。如果这些都不可用，与开发人员进行快速跟进电话将准确产生预期的屏幕。在我们继续进行时，请随意跟随并练习。该流程不仅限于用户界面，还可用于绘制 API 到 API 调用、数据库图表、依赖结构等。同样的原则也适用。

条件、状态、动作

我们只使用三个演员来限制我们的流程。您将拥有一个Condition ，它就像具有特定角色的用户、已清除的缓存或第一次登录的用户。其次，我们有一个State/Page ，它是一个实际的 GUI 组件，例如主页或登录窗口。接下来是Action ，它是一种导致状态改变的物理用户交互。让我们看看这一点。

分析需求

这是我们的主页，也就是国家。我们有两种可能的操作：注册和登录。

然后，我们有另一个状态的登录窗口。这里的操作是返回和登录。请注意，我们不会将输入字段分类为操作。非常欢迎您这样做。根据我的经验，我发现在处理运行十分之几的复杂系统时，维护起来有点困难，但对于简单的应用程序，它可能非常适合。

最后，我们来到用户成功登录后将登陆的仪表板。在这里，我们有三个操作——我们可以创建、编辑或删除消息。

我们现在有足够的信息来开始用户流程。让我们总结一下我们所拥有的。我们记下产品的状态。我们可以看到，有四个页面：

主页
登录窗口
注册窗口
仪表板

我们在每个可以与之“交互”的页面/状态上写下我们的操作：

主页
1. 登录
2. 登记
登录窗口
1. 登入
2. 取消
注册窗口
1. 待定（取决于产品）
仪表板
1. 创建
2. 编辑
3. 删除

我们从Product Name开始，它可以更改以适应您的环境，但这适合大多数团队及其产品，也提供了一个很好的起点。下面，我们会注意到Register旁边有一个问号。

很多时候，您会遇到敏捷中的一个组件，该组件尚未在范围内或计划用于未来版本。请注意它的存在，但在我们获得更多信息之前将其保留为未知数。

绘制流程图

我们在 XMind 中画出上面的样子：

你会注意到我只是用颜色编码什么是状态和什么是动作。我还在主页中添加了取消操作中的一行以准确表示该流程。当用户选择“登录”时，我们还会看到两个条件。尽管两者都进入仪表板，但我们仍然想测试这两种可能的情况。

XMind 的好处是，如果我们在一个大型、复杂的应用程序上工作，我们可以创建不同层次的图表，所以如果你想将流程分解为多个流程但保持它们链接，链接很容易做到分开工作表的主题。您可以选择插入超链接，并从向导弹出窗口中选择操作导致的“状态”。这意味着如果您在 XMind 上选择“登录”并且它超链接到“仪表板”，您的鼠标光标将跳转到“仪表板”，即使它在不同的工作表上。很酷。

我们的流程缺少的是标签。我们给产品一个标签 0，因为这是流程的根。然后，为每个状态（蓝色）添加一个 S# 标签，为每个动作（绿色）添加一个 A# 标签，最后，为每个条件（青色）添加一个 C# 标签。每个标签必须是唯一的。我们最终得到以下结果：

要跟踪您上次使用的数字——因为随着产品的增长，尝试找到最高数字可能具有挑战性——我将其存储在流程的根主题中，如下所示：

我们现在来到创建测试用例的部分。我们将重点关注预期结果，这可能是测试用例中最重要的信息，也是功能验收标准的一部分。我将为每个部分或测试添加一个标题，然后在其下列出预期的结果。我将只对一个子集执行此操作以保持本文简洁：

然后，登录窗口：

然后，登录操作：

它真的正在成形。注意添加的边界和安全测试。您可以随意命名，以最容易标记的为准。我有时会用测试类型标记标题，例如安全 - JS 注入 - 电子邮件字段，然后在下面列出预期的结果。

在大多数团队中，我们发现不断变化的需求很难维护。不再。假设我们刚刚了解到，所有首次使用的用户都必须看到 Ts 和 Cs 窗口，并且必须在继续访问他们的仪表板之前接受 - 没问题。我们可以相对容易地添加状态和动作，如下所示：

我们现在看到了添加新状态的影响。请注意，编号一开始可能很奇怪，但只要我们记得，编号只是用来唯一标识每个参与者——很像数据库中的主键。不要忘记更新您的“上次使用”笔记以跟踪您使用的数字。

从流中创建测试用例

在所有这些进展之后，我们现在进入更简单的部分：测试用例创建。让我强调一些要点。我们有每个演员的标签，我们有每个测试的标题，我们有每个测试的预期结果，并将条件嵌入到我们的流程中。这听起来像是测试用例的秘诀，你不同意吗？

我们现在所做的就是将流程中的内容复制粘贴到您希望的任何测试用例管理工具、Confluence 站点或 Excel 文档中。我仍然使用旧的可信赖的 Excel。我将所有测试用例记录在一个名为“基线”的文件中——非常原始。完成复制粘贴后，我得到以下结果：

根据需要随意添加测试类型、测试状态和测试配置列。条件可能最好放在“登录”操作之前，但是，没有正确或错误的方法，这取决于个人喜好和您如何组织自己。

有几点需要强调。一是我已经合并了共享相同信息的单元格——不需要重复复制粘贴，它浪费时间并且更难维护。另一个项目是步骤。您会注意到其中两个测试包含包含状态和操作编号的步骤。当您将流作为团队中 SDLC 的一部分时，可以使用此功能。然后，所有利益相关者通过提供信息、模型、提高风险等来为流程做出贡献。这意味着通过说明流程数字，团队中的任何人都会知道该怎么做，如果有新的团队成员，这也很容易如“循序渐进，参考注释”。

这也有助于自动化。您可以为每个步骤或操作提供唯一的参考。通过创建一个结构类似于您的流程的自动化包，您会发现您可以构建的自动化框架具有高度健壮、模块化和跨应用程序兼容的潜力。它将更大规模地使用分页对象，这将减少维护时间并允许您将测试功能换成新功能。

流程可以是所有产品文档的唯一真实来源，包括技术规范、功能规范、测试用例、状态转换、数据流等。

简化的测试计划方法

那么测试计划呢？你一定在想。这很简单。测试计划包含以下部分：

简介和范围
测试项目
要测试的功能
无需测试的功能
假设
进入标准
退出标准
工作分解结构
风险
环境要求

简介和范围将是 JIRA 故事或其他工具中的任何任务或故事。测试项目只是当前部署在您的环境中的软件版本或提交编号，您可以链接到 JIRA 票证或在 Confluence 或测试管理工具上运行的测试。

要测试的功能和不测试的功能实际上是您的测试用例。为这个 JIRA 故事选择执行的测试用例是“要测试的功能”，任何未列出的都是“不要测试的功能”。很简单，列出您将在故事票证上测试的状态和动作。

假设、风险甚至环境要求可以编译到文档中或添加到 JIRA 的评论中，有时甚至可以放在 Confluence 上并链接到故事。

WBS 是您根据故事点或小时数分配给故事的估计值，具体取决于您的项目。进入和退出标准已经成为故事的一部分。

如果你想接近“传统”的测试计划，你可以要求开发人员或其他利益相关者用是或否来评论这个故事，看看他们是否同意 QA 计划。这在技术上用作您的数字签名。所有这些都可以很容易地包含在您的 QA 流程中，并帮助您简化 QA 文档。

我们学到了什么？

采用上述方法和简化测试计划以使用当今可用工具的用户流程将帮助我们减少重复性工作并帮助 QA 在不牺牲质量的情况下实现更快的周转时间。

这种方法有助于指导我保持井井有条，涵盖每一个基础，并构建整个团队都能理解的文档。在敏捷中，这真的会派上用场，其中最好的部分是我们仍然遵守敏捷方法之一： “简化文档”。

我真的希望这些信息对您有所帮助。这完全取决于你作为读者。这不是一套要遵循的具体规则，这些只是为您提供发展和提高效率的想法的指导方针。没有一种技术适合每个项目、团队或产品，但它可能为另一个创新想法铺平道路。