每天‬分享‬最新‬软件‬开发‬，Devops，敏捷‬，测试‬以及‬项目‬管理‬最新‬，最热门‬的‬文章‬，每天‬花‬3分钟‬学习‬何乐而不为‬，希望‬大家‬点赞‬，加‬关注‬，你的‬支持‬是我‬最大‬的‬动力‬。

QA 工程师参与的项目范围从小型维护项目、紧急修复（跨越 1-2 天或更短时间）、中型项目（跨越数周或数月）到全面的大型项目（可持续长达一年或更多的）。虽然这些项目中的每一个在测试工作和资源方面可能有所不同，但它们都遵循共同的测试过程。

让我们将此测试管理流程分为 3 类：

• 测试需求策略
• 测试用例设计
• 测试执行

以有组织的格式收集测试需求，可用于创建测试计划和测试用例。为了有效地做到这一点：

• 查看可用的项目材料
• 安排与多个项目团队成员的会议，例如领域负责人、业务所有者、业务分析师和项目负责人。
• 确保所有项目团队成员审查测试要求
• 将测试需求转化为测试计划，然后是测试用例

测试用例设计活动主要围绕功能系统测试解决。设计测试用例通过创建测试条件作为整体验收标准的一部分来确保实现系统要求和规范。可以使用以下准则创建测试用例：

• 高级测试用例（HLTC）：无需详细步骤即可创建测试用例。一个高级测试用例可以像“成功登录网站”这样简单
• 测试用例评审：作者应在将 HLTC 分配给同行评审之前对其进行评审。同行评审是一种强制检查，以检查测试覆盖率是否完全基于收集的要求。并非所有组织都遵循这一点，但采用它来确保有良好的测试覆盖率是一种很好的做法。
• 详细的测试用例：一旦完成同行评审，就会创建详细的测试用例。它更精细，通常写有详细信息，包括描述、步骤（如果需要）、预期结果、实际结果、附加说明和测试参数（如果有）
• 测试策略和策略：必须在早期规划不同的测试方法和技术，QA 工程师利用可用于开发和执行测试用例的功能性和非功能性技术的平衡。测试包括用于测试阳性和阴性结果的对照。

创建测试用例时，请遵循以下格式：

标题：标题应该简明扼要，包括快速识别正在测试的内容、预期的内容以及在什么条件下运行测试所需的基本信息。它应该在标题情况下

功能区：[特征]（应该|不应该）行为[何时]

功能区：这是必需的。它是正在测试的高级功能区域或组件。

功能：这标识了正在测试的特定功能。通常是必需的。如果该功能是隐含的，则可以省略。比如在登录功能区测试错误的时候，或者整个功能区都在测试的时候。

应该 | 不应该：这是必需的，如果测试确认发生了某些事情，请使用应该。如果确认某事没有发生，请使用“不应该”。

行为：这是必需的，它解释了应该或不应该发生的事情

时间：这解释了在什么情况下运行测试，例如“用户名无效时”。如果未包含在标题中，则暗示“每次”。

测试用例步骤旨在让测试人员知道如何为测试准备系统以及如何测试功能。它们应该包含足够的细节，以便对应用程序有基本了解的人可以选择一个测试用例并用最少的问题执行它。他们不应该假设测试用例的用户是专家。如果需要详细说明来解释如何执行特定步骤，则应链接到带有详细信息的票务跟踪系统。这样，如果由于程序更改而导致指令更改，则只需更新一个地方。

测试用例必须遵循GIVEN - WHEN - THEN规则。这以结构化格式提供了用于表达场景的文档。

对于特定场景，您分析三件事：

GIVEN ：测试动作之前的先决条件是什么。系统中有哪些数据？参数集是什么？

WHEN：将测试哪些输入数据？需要采取哪些行动？

THEN：响应动作（WHEN），可观察到的结果应该是什么？预期的行为或结果是什么？

给定：

应该至少有一个“给定的”测试步骤。但是，如果 Given 是 None 那么它可以被省略。这应该是比较少见的。要求是：

• 必须以“Given”开头，表示它是先决条件，是测试用例的一部分
• 预期结果中不能有任何内容，因为“给定”步骤不是测试的重点
• 如果“给定”步骤失败，则测试用例将被视为阻塞，而不是失败。
• 对于如何执行不明显的复杂先决条件，请包含指向工单跟踪系统或其他文档的链接，以便从未运行过测试的人知道该怎么做

什么时候：

这些是用户执行测试所采取的步骤。要求是：

• 必须以“When”开头，以表明这是一个实际步骤。如果使措辞变得尴尬，有时可以省略“时间”。
• 预期结果中必须有“Then”
• 如果是一个多步骤动作，“那么”应该从最后的“何时”开始。

然后：

这解释了“何时”步骤的预期结果。因此，它应该在预期的结果中。要求是：

• 不需要包括“那么”，因为这是在预期结果中暗示的。
• 在action中必须有对应的when。如果是多步骤结果，那么所有步骤只能有一个“时间”。
• 单个“然后”步骤可以有多个“何时”预期结果。

多步骤操作和结果

如果一个动作或结果由多个步骤组成，它可以分成多行，每一行应该在一个单独的行中，缩进四个空格，并以大写 AND 开头。这允许用户看到它是一个单独的测试，但允许在运行它时检查每个步骤并通过或失败。例如：

标题：成功登录“X”网站

行动 预期结果

给定一个“X”网站的 URL

当用户输入有效的用户名 THEN 用户能够成功登录

和密码“X”网站

当您收到审核请求时，审核者可以按照以下清单进行操作：

• 确保用户遵循标准的测试用例格式。
• 验证用户是否遵循了要求并且测试用例具有功能覆盖。
• 寻找多余的测试用例并请求将其删除。
• 有可能两个或多个测试用例可以测试同一件事，并且可以通过使用参数合并为一个。
• 测试数据必须附加到测试用例链接到测试数据存储库必须在测试用例中提及。
• 一旦您查看了测试用例，请回复您的反馈和评论。
• 讨论并实施所需的更改。
• 在作者进行必要的更改（如果有）之后。审阅者可以签字，测试用例将准备好进行测试。

验收是在开发过程中根据可交付成果满足预定义标准的程度来批准或拒绝可交付成果的增量过程。QA 资源应鼓励客户、企业所有者或最终用户积极参与定义和评估所需的信息类型，并确定产品是否已准备好进入下一阶段。

从冒烟测试开始，以确定被测应用程序是否足够稳定以执行完整测试。

其次是 功能系统测试，重点关注以下 测试技术：

• 需求测试：目标是验证系统是否正确运行，并且正确性一直持续到系统开始运行
• 错误处理：这里的目标是验证系统是否可以正确处理不正确的数据。这是一个迭代过程，涉及反复试验，首先注入一个错误，然后纠正它，然后重新输入相同的错误以满足正确的错误处理周期
• 互连测试：大多数应用程序经常与一个或多个系统互连。目标是确保系统之间的互连正常运行
• 控制测试：此测试中包含的控制是数据验证、文件完整性、审计以及与政策和程序相符的系统相关完整性的其他方面。
• 跟踪测试结果以显示测试的通过/失败状态
• 将最终测试的屏幕截图附加到每个要求的票证上
• QA 资源可以选择根据风险、范围和变更类型执行选择性或完整的回归测试。在此过程中，应仔细评估每个组件对其他系统组件的影响。