上下文

制定战略或计划可能是开启许多成功的关键，这对于生活中的大多数情况都是如此，无论是体育、商业、教育等等。对于向最终用户/客户提供软件/应用程序解决方案的任何公司或组织来说，情况也是如此。如果您将范围从工程进一步缩小到敏捷，然后再缩小到测试或质量工程，那么战略和规划在每个层面都是关键。

让我们放大软件测试或质量工程上下文。无论是在产品、领域、项目还是公司范围内制定测试策略，这可能会非常令人生畏，因为需要考虑许多方面和因素，再加上可能足以引起内心恐惧的掩护那些需要执行任务的人。在这篇文章中，我希望让这项任务变得更容易，并制定一个潜在的蓝图或在制定测试策略时要考虑的领域

计划

请记住，不同的人在许多不同的环境、设置、技术和结构中进行操作，想出一个通用的测试策略似乎是不可能的。但是，如果缩小并尝试提取要考虑的关键因素，则可以清楚地看到一些定制测试策略的路径。多年来，我在许多不同行业、公司规模、方法和技术方面的经验使我能够提取这些因素进行跟踪，以便最大限度地覆盖测试策略。

作为质量工程师和测试人员，我们的期望是尝试在每个领域获得尽可能多的测试覆盖率，以最终确保与交付的解决方案相关的最高质量，那么我们从哪里开始呢?

在处理测试策略创建时，我通常会尝试通过使用工具集思广益来可视化我试图涵盖的内容。我尝试在空白画布上开始我的可视化，然后扩展以涵盖以下关键区域：人们、过程、技术

一旦我有了这些，我通过将 5W1H 概念结合到上面的每个区域来进一步扩展它。所以通常我会问什么、为什么、谁、何时、何地和如何?与上面的每个区域相关，但这完全是可选的。这有助于我验证和支持我的方法。我这样做是为了确保在解决理想的测试策略时涵盖所有可能的差距。

不断发展的战略

1、人：我通常喜欢围绕人开始我的战略，因为他们是任何成功战略的关键。所以通常在这里通过结合 5W1H 技术来支持我的想法，它可以开始形成这样的形式：

我们的 QA 工程师有什么期望?他们将覆盖什么?我们将在 QA 团队/章节中扮演哪些不同的角色?- 这有助于确保您了解需要涵盖的内容

为什么我们需要他们来承担这些角色和任务?- 在这里你会确保你验证你为什么做某些事情

谁来开展工作?这可以帮助您解决任何短缺问题或如何战略性地构建团队以提高效率

QA 工程师应该什么时候执行他们的任务?这部分以在哪些阶段需要更多的 QA 参与为例

我们的 QA 工程师在哪里?它们的物理位置应该在哪里?如果我们需要聘用我们的 QA 工程师，我们将从哪里获得他们?理想情况下，这将允许您覆盖许多领域，从我们的 QA 团队/分会的实际位置，以使我们能够有效地工作到我们实际雇用他们的地方。

QA 章节的结构如何?他们将如何跨项目移动?

2、过程——在本节中，重点与实际方面或日常活动有关。谈到流程和技术/工具，我可以进一步将其分为与“交付”和“工艺”相关的另外两个部分。这允许人们从实际性质确保更多的覆盖范围。您还可以在遍历此处的每个区域时再次添加 5W1H 技术，但在接下来的 2 节中我不会过多地介绍这些细节，因为我已经介绍了上面的概念。

1）交付：在本节中，我专注于实际的实施方面。因此，无论使用什么流程/框架，我都会尝试涵盖与此相关的 QA 和测试的实际方面。例如，如果使用 Scrum，那么我将介绍以下与 QA 和测试过程相关的内容：

冲刺级别：

冲刺前：测试所需的准入标准是什么

冲刺：QA 场景识别和文档，追溯故事、冲刺测试自动化、缺陷记录周期和过程，缺陷仪表板、退出标准

冲刺后：冲刺后 QA 活动、风险

我们可以进一步扩展到与交付相关的其他方面，例如发布和/或与交付测试环境、测试数据等相关的其他促成因素

发布级别：

QA 与发布相关的签核标准是什么、发布前 QA 和测试活动、发布后 QA 和测试活动、发布质量检查清单、发布/发布风险/缓解建议

测试环境(这可能是交付或技术部分的一部分)：

定义将发生特定类型测试的测试环境、测试环境的可用性和签核所需的先决条件

测试数据(这可能是交付或技术部分的一部分)：

涵盖测试数据的方面、测试数据可用性、屏蔽和匿名化。

文档和结果：

我们计划如何保存结果，以什么格式保存，保存多长时间?是否有法律要求保留此内容?

2）工艺：为了补充上述想法，确保获得全面覆盖的下一步是将与 QA/测试相关的方面定义为工艺。这样做的目的是将最佳实践作为 QA/测试学科纳入定制交付方面(这会因公司而异)。再一次，您也可以通过在此处结合 5W1H 技术来补充思维过程。这里要涵盖或记住的一些关键方面是：

测试级别：我们是否希望涵盖单元测试、组件测试、集成测试和 UI 测试?如果是这样，那么谁来负责做这件事?如何做?此类测试将在流程的哪个阶段进行(何时)?这种类型的测试将在哪里进行?每种类型将涵盖哪些内容?

测试类型：我将其分为功能测试和非功能测试，并尝试涵盖与测试文档(如果有)、功能方面的探索性测试和非功能方面的负载/性能/安全性/可访问性等相关的方面。我稍后会用每种测试类型使用的实际工具/技术来覆盖和补充这部分。

3）技术和工具：最后，作为我计划的一部分，我考虑的最后一个重点领域是从 QA/测试的角度制定与技术和工具相关的综合测试策略。再次确保不遗余力，我还合并了上面提到的两个部分，即。'Delivery' 和 'Craft' 也用 5W1H 的思维技术再次验证了我的想法。

交付 - 如上所述，本节我关注实际方面，因为从技术和工具的角度来看与交付相关的几点包括：

我使用什么工具来捕获我的测试场景/案例(例如 TestRail、XRay)、我将使用哪些工具/软件来发送我的 API 请求?需要哪些其他工具来支持我的测试交付任务和活动、每种测试类型所需的测试自动化工具(基于提到的测试类型)、日志/监控需要什么访问权限才能支持测试?

工艺——从技术和工具的角度来看，我通常关注这些领域的最佳实践，这些领域可能再次完全独立于公司，并且可以被认为是与技术/工具实施相关的即插即用概念。例如，我可以在这里进一步拆分与测试自动化和技术测试相关的内容。然后在与功能性和非功能性工具特定的最佳实践相关的测试自动化方面有进一步的子类别。其中一些可能包括：

功能测试自动化—UI 覆盖：遵循 BDD 风格的 Selenium webdriver(然后进一步详述细节)、API 覆盖范围：JS Jest 与 SuperTest - 然后深入了解、移动测试自动化：Appium 等

非功能测试自动化—负载/性能测试：JMeter – 命名该领域的最佳实践、安全测试：OWASP- 加上这里的最佳实践扩展。

测试自动化执行—云执行：LambdaTest – 在此处提供更多详细信息

技术测试方面：与 Swagger、Postman API 测试中的最佳实践等相关、测试 RabbitMQ、Kafka 等

结论

测试策略可以像一个巨大的螺旋形门户，可以带您穿越许多不同的维度，但是如果遵循上面提到的某些方面，那么围绕与测试策略覆盖率相关的扎实进展的重点就更近了。上述方法主要可用于启动和创建将进入最终测试策略的内容(以您选择的格式)，但是您可以确信通过触摸上述每个部分并使用验证每个部分5W1H 技术，您应该能够很好地创建可靠的测试策略。

Meta url : blueprint-for-test-strategy

Meta Title: Blueprint for Test Strategy Creation

Meta Description: 测试策略就像一个巨大的螺旋形门户，可以带你穿越许多不同的维度。有许多方面和因素需要考虑，外加掩护足以让需要执行任务的人感到恐惧。

卓码软件测评是一家[ 具备CMA、CNAS双重资质 ]的专业做软件测试的第三方软件测试服务机构, 可根据您的需求提供各类软件测试服务，并出具合格有效的软件测试报告。点击→→可了解测试报价

部分文字、图片来自网络，如涉及侵权，请及时与我们联系，我们会在第一时间删除或处理侵权内容。负责人：曾菲       电话：4006070568