随着产品和服务的部署越来越快, 质量保证(QA)必须适应不断变化的环境, 有时在较短的时间内达到相同的覆盖水平. 我们如何避免犯……的错误 数量重于质量? 如何做到覆盖面大、效率高、工作有效?

我们都知道创建测试用例需要很长时间. 我们必须运用不同的技术, 测试类型, 记录前提条件, 步骤, 预期结果. 另外，我们必须创建一个测试计划.

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

传统的QA测试符合用户流程

我是传统测试用例和测试计划的忠实粉丝. 它们不仅帮助识别大量的测试用例，而且还很好地记录了产品. 你可以在训练中使用它们，团队中的任何人都能理解它们. 你不必过分依赖经验让别人开始 测试. 测试计划有进一步的信息，比如详细的范围, 测试项目, 您正在测试的功能, 那些你不是的人. 在测试计划中也有一个风险分析. 这些只是一些好处，然而，在许多情况下，它花费的总时间太长了.

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

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

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

随波逐流

不要再拖延了，让我们直接进入 构建用户流 对于一个简单的信息网站.

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

我们的第一步是了解产品. 通常，您将参考模型图像或线框图. 如果这些都不可用, 与开发人员进行一次简短的电话交流，就能得到预期的屏幕效果. 在我们进行的过程中，请随意跟随和练习. 该流不仅限于用户界面，还可以用于映射api到api的调用, 数据库关系图, 依赖结构, 和更多的. 同样的原则也适用.

条件，状态，行动

我们通过只使用三个参与者来限制流. 你会有一个 条件, 哪个是具有特定角色的用户, 已清除的缓存, 或者用户第一次登录. 其次，我们有 州/页，它是一个实际的GUI组件，如主页或登录窗口. 接下来是 行动，这是导致状态改变的物理用户交互. 让我们看看这是怎么做的.

需求分析

这是我们的主页，也就是国家. 我们有两个可能的操作:注册和登录.

然后，我们有Sign In窗口，另一个状态. 这里的操作是Back和登录. 注意，我们没有将输入字段归类为操作. 非常欢迎你来做这件事. 根据我的经验, 我在处理复杂的系统时发现了这一点, 维护起来有点困难, 但是对于简单的应用程序, 这是一个非常合适的工作.

最后，当用户成功登录时，我们将进入仪表板. 在这里，我们有三个操作—我们可以创建、编辑或删除消息.

现在我们有了足够的信息来开始用户流. 让我们总结一下我们所拥有的. 我们记下产品的状态. 从我们所看到的来看，有四页:

1. 主页
2. 登录窗口
3. 注册窗口
4. 指示板

我们在每个可以“交互”的页面/状态上写下我们的动作:

1. 主页
   1. 登录
   2. 注册
2. 登录窗口
   1. 登录。
   2. 取消
3. 注册窗口
   1. 待定(视产品而定)
4. 指示板
   1. 创建
   2. 编辑
   3. 删除

我们从 产品名称, 哪些可以改变以适应你的环境, 但这适合大多数团队和他们的产品，也提供了一个很好的起点. 下面，我们会注意到旁边有一个问号 注册.

很多次, 在敏捷中，你会遇到一个还不在范围内的组件，或者还没有计划在未来发布. 注意它的存在，但在我们得到更多信息之前，把它作为一个未知数.

绘制流程图

我们在XMind中将上面的代码绘制为:

您将注意到，我只是用颜色标记了什么是状态，什么是动作. 我还在主页上添加了一行取消 行动，以准确地表示该流程. 当用户选择“登录”时，我们还看到两个条件.“虽然两种情况都会出现在仪表盘上，但我们仍然希望测试两种可能的情况.

XMind的好处是，如果我们在一个大的, 复杂的应用程序, 我们可以创建图表的不同层次, 所以如果你想把流程分解成多个流程，但要保持它们之间的联系, 通过将主题链接到单独的表单，这是非常容易做到的. 您可以选择插入一个超链接, 从向导弹出, 你可以选择一个动作所指向的“状态”. 这意味着如果你在XMind上选择“登录”，它会超链接到“指示板”,，您的鼠标光标将跳转到“仪表盘”,即使是在另一张纸上. 很酷.

我们的流程缺少的是标签. 我们给乘积一个0的标签，因为它是流的根. 然后, 每个州(蓝色), 我们添加了一个s#标签, 对于每个动作(绿色), 我们添加一个a#标签, 最后, 每种情况(青色), 我们添加了一个c#标签. 每个标签不能重复. 我们最终得到以下结果:

跟踪你最后使用的号码——因为随着产品的增长, 试图找到最高的数字可能是一个挑战—我将其存储在流的Root主题中, 像下图:

现在我们来到了创建测试用例的部分. 我们将重点关注预期结果, 在测试用例中，哪些可能是最重要的信息，哪些可能是特性验收标准的一部分. 我会为每个部分或测试添加一个标题，然后在下面列出预期的结果. 为了保持本文的简洁，我将只对其中的一个子集这样做:

然后，登录窗口:

然后，签名行动:

它确实正在成形. 注意添加的边界和安全性测试. 你可以给它起任何你喜欢的标题，哪个对你来说是最容易标记的. 我有时用测试类型标记标题, 如安全- JS注入-电子邮件字段, 然后在下面列出预期的结果.

在大多数团队中，我们发现变更需求的维护非常麻烦. 没有更多的. 假设我们刚刚了解到，所有首次使用的用户都必须看到t和c窗口，并且在进入仪表板之前必须接受，这没问题. 我们可以相对容易地添加状态和动作，如下所示:

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

从流中创建测试用例

在所有这些进展之后，我们现在进入更容易的部分:测试用例创建. 让我强调一些要点. 我们给每个演员都贴上了标签, 每个测试都有题目, 我们对每个测试都有预期的结果, 作为我们流程的一部分嵌入条件. 这听起来像是测试用例的配方，您不同意吗?

我们现在所做的就是将流中的内容复制粘贴到任何测试用例管理工具中, 汇流网站或Excel文件，你想. 我还在用值得信赖的Excel. 我将所有测试用例的记录保存在一个名为“基线”的文件中——非常原始. 一旦我完成了复制粘贴，我结束了下面:

您可以根据需要随意添加测试类型、测试状态和测试配置的列. 在“Sign In”操作之前设置条件可能会更好, 然而, 做这件事没有对错之分, 这取决于个人偏好和你如何安排自己.

有几件事需要强调. 一个是我合并了共享相同信息的单元格——不需要重复复制粘贴, 它浪费时间，而且更难维护. 另一项是步骤. 您将注意到，其中两个测试的步骤包含状态和操作编号. 当您在团队中将流作为SDLC的一部分时，可以使用此方法. 然后，所有涉众通过提供信息、模型、增加风险等方式对流程做出贡献. 这意味着通过说明流号, 团队中的每个人都知道该怎么做, 如果有新的团队成员, 这就像“沿着小路走”一样简单, 参考笔记.”

这也有助于自动化. 您可以为每个步骤或操作提供唯一的引用. 通过创建一个结构类似于流的自动化包, 您将发现您可以构建的自动化框架具有高度健壮性的潜力, 模块化, 并且在整个应用程序中兼容. 它将在更大的范围内利用分页对象, 这将减少维护时间，并允许您将测试功能替换为新的功能.

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

流线型测试计划方法

那么测试计划呢?你一定在想. 这很简单. 测试计划包含如下部分:

1. 介绍 & 范围
2. 测试项目
3. 要测试的特性
4. 不需要测试的功能
5. 假设
6. 入口准则
7. 退出标准
8. WBS
9. 风险
10.  环境的要求

介绍和范围将是 JIRA 故事或其他工具中的任何任务或故事. 测试项只是当前部署在环境上的软件版本或提交号, 您可以链接到JIRA票据或在您的测试运行 融合 或者测试管理工具.

要测试的特性 和 不需要测试的功能 实际上是你的测试用例吗. 为这个JIRA故事选择执行的测试用例是“要测试的功能”,，任何未列出的都是“不需要测试的功能”.“很简单，在故事单上列出你将要测试的状态和行动.

假设, 风险, 甚至可以将环境需求编译成文档或添加到JIRA的评论中, 有时甚至放在合流和链接到故事.

WBS是您根据故事点或小时分配给故事的估计, 取决于你的项目. 入境和出境标准将已经成为故事的一部分.

如果您想要接近“传统”的测试计划, 你可以让开发者或其他利益相关者对故事做出“是”或“否”的评论，看看他们是否同意QA计划. 这在技术上充当您的数字签名. 所有这些都可以很容易地包含在你的QA过程中，并帮助你简化QA文档.

我们学到了什么??

使用上述方法和测试计划的用户流程将帮助我们减少重复工作，并帮助QA在不牺牲质量的情况下实现更快的周转时间.

这种方法在指导我保持组织，覆盖每一个基础，和 构建整个团队都能理解的文档. 在敏捷, 这真的会派上用场, 最好的部分是我们仍然遵循敏捷方法之一: “简化文档.”

我真心希望这些信息对你有所帮助. 这完全取决于作为读者的你. 这并不是一套需要遵循的具体规则, 这些只是给你成长和提高效率的建议. 没有一种技术适合每个项目, 团队, 或产品, 但它可能为另一个创新想法铺平道路.