QA工程师的测试管理

质量工程师参与项目从小型维修项目,紧急修复,中档项目全面大项目。

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

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

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

1. 测试需求策略

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

2. 测试用例设计

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

测试用例格式

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

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

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

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

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

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

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

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

测试用例步骤

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

格式：

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

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

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

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

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

给定：

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

什么时候：

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

然后：

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

多步骤操作和结果

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

标题：成功登录“X” 站

行动 预期结果

给定一个“X” 站的 URL

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

和密码“X” 站

查看测试用例

3. 测试执行

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

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

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