软件测试——测试策略

测试策略文档是一个高级文档，它概述了软件开发生命周期中使用的测试技术，并确认了将在产品上执行的测试类型或级别。测试策略一经编写就无法更改，并且已被项目经理和开发团队接受。

此外，测试策略提供了以下详细信息，在编写测试文档时需要这些信息：

除此之外还必须使用什么技术？
哪些模块将被检查？
什么标准适用于进入和退出？
需要进行什么样的测试？

换句话说，它是一个解释产品评估过程的文件。可以使用以下因素开发这些方法：

是否自动化
从资源的角度

在开发设计论文的基础上，我们可以编写测试策略。

开发设计文档中包含以下文档：

与系统设计相关的文档：这些文档将主要用于构建测试策略。
设计文档：这些用于概述将在未来版本中启用的软件功能。
与概念设计相关的文件：这些是我们不经常使用的文件。

在这里，我们将讨论以下几点：

测试策略的组成部分。
测试策略与测试计划。
测试策略的类型。
测试策略选择。
测试策略文档中包含的详细信息。
结论。

测试策略的组成部分

测试策略中概述了用于验证和验证一组功能的测试工作、测试域、测试设置和测试工具。它还包括时间表、资源分配和员工利用率信息。这些数据对于测试团队（Test）尽可能结构化和高效至关重要。测试策略不同于测试计划，测试计划是按功能区域和/或测试类型以可以呈现给其他团队和/或客户的格式收集和组织测试用例的文档。两者都是质量保证过程的关键组成部分，因为它们有助于传达测试方法的广度并确保测试覆盖率，同时提高测试工作的效率。

以下是测试策略的组成部分：

范围和概述。
测试方法。
测试环境规范。
测试工具。
释放控制。
风险分析。
审查和批准。

测试策略文档的组成部分

让我们详细讨论其中的每一个。

1.范围和概述：范围和概述是测试策略文件的第一部分。任何产品的概述都包括有关谁应该批准、审查和使用文档的信息。测试策略文件中还描述了必须批准的测试活动和阶段。

该项目的概述，以及有关谁应该使用此页面的信息。
包括谁将评估和批准文件等信息。
定义将要执行的测试活动和阶段，以及与测试计划中规定的总体项目时间表相关的时间表。

2. 测试方法论：测试方法论是测试策略文档中的下一个模块，用于指定所有团队成员的测试程度、测试程序、角色和职责。变更管理过程，包括修改请求提交、要使用的模式和管理请求的活动，也包含在测试策略中。最重要的是，如果没有正确建立测试计划文件，可能会导致未来的错误或失误。该模块用于指定以下信息-

定义每个团队成员的测试过程、测试级别、角色和职责。
描述为什么要在测试计划中定义每种测试类型（例如，单元、集成、系统、回归、安装/卸载、可用性、负载、性能和安全测试），以及何时开始等细节、测试负责人、职责、测试方法以及自动化策略和工具的详细信息（如果适用）。

3.测试环境规范：测试环境规范是测试策略文件的另一部分。众所周知，测试数据要求的规范非常重要。因此，测试策略文档中的测试环境规范包括关于如何生成测试数据的明确说明。此模块包含有关环境数量和所需设置的信息。备份和恢复的策略同样重要。

有关环境数量和每个环境所需配置的信息应包含在测试环境设置中。
例如，功能测试团队可能有一个测试环境，而 UAT 团队可能有另一个。
定义每个环境支持的用户数量，以及每个用户的访问角色和软件和硬件要求，例如操作系统、RAM、可用磁盘空间和系统数量。
定义测试数据需求同样重要。
给出有关如何生成测试数据的具体说明（生成数据或通过屏蔽字段来使用生产数据以保护隐私）。
定义测试数据的备份和恢复策略。
由于代码中未处理的情况，测试环境数据库可能会遇到问题。
备份和恢复方法应说明备份时由谁进行备份、备份中应包含哪些内容、何时恢复数据库、由谁来恢复以及恢复数据库时应执行哪些数据屏蔽程序。

4.测试工具：测试工具是测试策略文档的重要组成部分，因为它包含了测试执行所需的测试管理和自动化工具的所有信息。用于安全、性能和负载测试的必要方法和工具取决于开源或商业工具的详细信息以及它可以支持的用户数量。

定义用于执行测试的测试管理和自动化工具。
描述性能、负载和安全测试所需的测试方法和工具。
提及产品是开源的还是商业的，以及它可以容纳的人数，并做出适当的规划。

5. 发布控制：发布控制是测试策略文档的重要组成部分。它用于确保以系统的方式建立测试执行和发布管理策略。它指定了以下信息-

测试和 UAT 环境中的不同软件版本可能来自计划外的发布周期。
该版本中的所有调整都将使用发布管理策略进行测试，其中包括适当的版本历史记录。
建立一个构建管理流程，回答以下问题：新构建应该在哪里可用，应该在哪里部署，何时接收新构建，在哪里获取生产构建，谁将为生产发布发出 go 信号，以及很快。

6. 风险分析：风险分析是测试策略文件的下一部分。与项目相关的所有潜在危险都在测试策略文档中进行了描述，并且可能在测试执行期间成为问题。此外，还制定了一个明确的策略来降低这些风险，以确保它们得到适当的执行。如果开发团队实时面临这些危险，我们会制定应急计划。列出所有潜在的危险。提供管理这些风险的详细计划，以及在危害发生时的备用计划。

7.审查和批准：审查和批准是测试策略文件的最后一部分。

当所有测试活动都在测试策略文档中说明时，由相关人员进行评估，例如：

系统管理团队。
项目管理团队。
开发团队。
业务团队。

应遵循以正确日期、批准人姓名、评论和已审核修改的摘要开头的文档。

随着测试程序的改进，还应定期对其进行评估和更新。

测试策略与测试计划

以下是测试策略和测试计划之间的区别：

S No.	Test Strategy	Test Plan
1.	It’s developed from a set of software requirements (SRS).	It comes from a Business Requirement paper (BRS).
2.	The test lead or manager is in charge of preparing it.	The project manager or the business analyst creates it.
3.	The test plan’s components include the test plan’s id, features to be tested, test techniques, testing tasks, features pass or fail criteria, test deliverables, responsibilities, and timetable, among others.	The components of a test strategy include objectives and scope, documentation formats, test processes, team reporting structure, client communication strategy, and so on.
4.	After the requirements have been approved, the test plan is written.	The test strategy comes first, followed by the test plan.
5.	The test plan should be simple and straightforward.	The test approach serves as a general guide for the project at hand.

测试策略的类型

以下是不同类型的测试策略：

分析策略：例如，基于风险的测试和基于需求的测试是两种类型的测试。在检查了测试前提（例如风险或需求）后，测试团队设置要覆盖的测试环境。在基于需求的测试的情况下，检查需求以确定测试环境。然后创建、实施和运行测试以确保满足要求。甚至根据需求来跟踪调查结果，例如测试并通过的、测试但失败的、未完全测试的等等。
基于模型的策略：测试团队选择一个实际或预期的情况并为其构建一个模型，同时考虑输入、输出、过程和可能的行为。模型也是基于现有的软件、技术、数据速度、基础设施和其他因素创建的。让我们看一个您正在测试移动应用程序的案例。可以构建模型来模拟移动网络上的传出和接收流量、活动/非活动用户的数量、预测的增长和其他因素，以进行性能测试。
有条不紊的策略：在这种情况下，测试团队会遵守质量标准（例如 ISO25000）、检查表或只是一组测试环境。特定类型的测试（例如安全性）和应用程序域可能具有标准检查表。例如，在执行维护测试时，一份描述相关功能、它们的属性等的清单就足够了。
符合标准或流程的策略：遵循美国食品和药物管理局 (FDA) 指南的医疗系统很好地说明了这种方法。测试人员遵循标准委员会或企业专家小组制定的方法或建议来确定测试条件、确定测试用例并组建测试团队。在敏捷程序的情况下，测试人员将为每个用户故事创建一个完整的测试策略，从建立测试标准、开发测试用例、进行测试、报告状态等开始。
反应式策略：只有在发布真正的程序时，才会设计和实施测试。因此，测试基于在真实系统中发现的故障。考虑以下场景：您正在进行探索性测试。测试章程是根据已经存在的特性和功能创建的。测试人员的测试结果用于更新这些测试章程。敏捷开发计划也可以从探索性测试中受益。
咨询策略：同样，用户导向的测试使用来自关键利益相关者的输入来设置测试条件的范围，这种测试技术也是如此。让我们考虑一个正在评估任何基于 Web 的应用程序的浏览器兼容性的场景。在本节中，应用程序的所有者将按优先顺序提供浏览器列表及其版本。它们还可能包括要测试的程序的连接类型、操作系统、反恶意软件和其他要求的列表。根据提供列表中项目的优先级，测试人员可以使用各种策略，例如成对或等价拆分。
回归规避策略：在这种情况下，测试程序旨在降低功能性和非功能性产品方面的回归风险。以 Web 应用程序为例，如果程序需要针对回归问题进行测试，测试团队可以针对常见和不常见的用例设计测试自动化。他们还可以在每次更新应用程序时使用基于 GUI 的自动化工具进行测试。上述任何策略都不必用于任何测试工作。根据产品和组织的需要，可以集成两个或多个策略。

测试策略选择

以下因素可能会影响测试方法的选择：

选择的测试策略取决于组织的性质和规模。
可以根据项目需要选择测试策略；例如，安全和安保应用需要更严格的技术。
可以根据产品开发模型选择测试策略。
这是短期策略还是长期策略？
组织类型和规模。
项目要求——安全和安保应用需要一个深思熟虑的策略。
产品开发模式。

测试策略文档中包含的详细信息

测试策略文档包括以下重要细节：

概述和范围。
可以重用的软件和测试工作产品。
有关各种测试级别、它们的关系以及集成各种测试级别的技术的详细信息。
测试环境的技术。
测试自动化水平。
各种测试工具。
风险评估。
对于进入和退出的每个级别的测试条件。
测试结果报告。
每个测试的独立程度。
在测试期间，将分析指标和测量值。
回归和确认测试。
照顾发现的缺陷。
配置和管理测试工具和基础设施。
测试团队成员的角色和职责。

结论

测试策略文档展示了测试团队将为整个项目做什么的美好愿景。因为测试策略文档将驱动整个团队，所以只有在产品领域有丰富经验的人才应该准备。因为它是一个静态文档，所以在整个项目生命周期中都无法对其进行编辑或更改。测试策略文档可以在任何测试操作开始之前发送给整个测试团队。如果测试策略文档被正确地创建，它将导致高质量系统的开发和整个测试过程的扩展。