不存在通用的软件测试过程，但是存在一些通用的测试活动集合，假如没有这些活动，测试很难实现它的既定目标。这些测试活动的集合就是测试过程。在任何给定的情况下，合适的和特定的软件测试过程依赖于很多因素。测试过程中涉及的测试活动、如何实施测试活动，以及测试活动何时发生，将会在组织的测试策略中讨论。
1.4.1 基于上下文的测试过程
影响组织测试过程的上下文因素包括但不限于：
•软件开发生命周期和使用的项目方法
•考虑的测试级别和测试类型
•产品和项目风险
•业务领域
•运作时的限制，包括但不限于：
o预算和资源
o时间
o复杂度
o合同和法规
o要求
•组织的方针和实践
•要求的内部和外部标准
后面章节从以下几个方面描述组织的测试过程：
•测试活动和任务
•测试工作产品
•测试依据和测试工作产品之间的可追踪性
针对测试依据（针对任何测试级别或类型）定义良好的度量覆盖率标准是非常有意义的。覆盖率标准能够作为关键绩效指标（KPIs）有效的驱动实现软件测试目标的活动（见1.1.1节）。
例如：针对移动应用，测试依据包括了需求列表和支持的移动设备列表。每个需求作为测试依据的一个元素。每个支持的设备也是测试依据的一个元素。覆盖率标准可以要求测试依据的每个元素至少有一个测试用例。一旦执行之后，这些测试结果可以告诉利益相关者具体的需求是否满足，以及在支持的设备上是否发现了失效。
更多测试过程的信息参考ISO标准（ISO/IEC/IEEE 291190-2）。
1.4.2 测试活动和任务
测试过程包括以下主要的活动组：
•测试计划
•测试监控
•测试分析
•测试设计
•测试实现
•测试执行
•测试结束
每组活动都由一系列的活动组成，这将在下面的小节中进行描述。每个活动组中的活动反过来可以包括多个独立的任务，这些任务在不同的项目或者发布中各有不同。
此外，尽管很多时候这些活动组从逻辑上看是顺序的，但是它们也常常是迭代实现的。例如：敏捷开发涉及软件设计、构建和测试的小迭代，这些小迭代是基于持续的计划活动基础上持续发生的。因此，在这种开发方式中，测试活动也是迭代持续发生的。即使在顺序开发中，逻辑上顺序的活动也会有重叠、合并、并行或者忽略，因此，通常需要在系统和项目的上下文中对这些主要活动进行裁剪。
测试计划
测试计划涉及定义测试目标和在上下文约束下符合测试目标的方法（例如：指定合适的测试技术和任务，制订满足最后期限的测试进度）。测试计划可以根据监控活动的反馈进行更新。5.2节将进一步的阐述测试计划。
测试监控
测试监视包括使用测试计划中定义的监控指标持续的将实际进度和计划进度做比较。测试控制涉及采取必要的行动以满足测试计划的目标（随着时间的推移可能会更新）。出口准则的评估可以为测试监控提供支持，出口准则评估在有些生命周期中被称为完成的定义（见ISTQB-AT初级敏捷测试扩展大纲）。例如：作为某测试级别的一部分，测试执行的出口准则评估包括：
•根据指定的覆盖率标准检查测试结果和日志
•根据测试结果和日志评估组件或系统的质量级别
•决定是否需要更多的测试（例如：如果原本要求达到一定产品风险覆盖率的测试无法满足覆盖率要求，则需要编写和执行额外的测试）
在测试进度报告中向利益相关者通报测试进度，包括与计划的偏差，以及支持作出停止测试决定所需的信息。
5.3节将有一步阐述测试监控。
测试分析
测试分析通过分析测试依据识别可测试的特性并定义相关的测试条件。换句话说，测试分析根据可度量的覆盖率标准确定“测试什么”。
测试分析包括以下主要活动：
•根据所考虑的测试级别分析测试依据，例如：
o需求规格说明，例如：业务需求、功能需求、系统需求、用户故事、史诗故事、用例或类似的指定想要的功能或者非功能组件或系统行为的工作产品
o设计和实现信息，例如：系统或软件架构图或文档、设计规格说明、调用流程、建模图（例如：UML或实体关系图）、接口规格说明或类似的指定组件或系统结构的工作产品
o组件或系统自身的实现，包括：代码、数据库元数据和查询，以及接口
•风险分析报告，其中会考虑组件或系统的功能、非功能和结构等方面
•评估测试依据和测试条目识别各种类型的缺陷，例如：
o歧义
o遗漏
o不一致
o不准确
o矛盾
o多余的语句
•识别要测试的特性和特性集
•基于测试依据的分析定义每个特性的测试条件，并进行优先级排序，同时考虑功能、非功能和结构化的特征、其它的商业和技术因素以及风险的级别
•获得测试依据中每个元素和相关测试条件之间的双向可追溯性
测试分析过程中使用黑盒、白盒和基于经验的测试技术，有助于减少遗漏重要测试条件的可能性，同时也有助于定义更加准确的测试条件。
在有些情况下，测试分析生成的测试条件可以用作测试章程中的测试目标。测试章程是有些基于经验的测试中典型的工作产品。当这些测试目标可以追溯到测试依据时，就可以度量基于经验的测试中能达到的覆盖率。
测试分析过程中识别缺陷是一个重要的潜在收益，尤其是在没有使用其它评审过程和/或测试过程和评审过程紧密联系时。测试分析活动不仅验证需求是否一致、表达是否正确和完整，同时可以确认需求是否正确的反映客户、用户和其它利益相关者的需要。例如：像行为驱动开发（BDD）和验收测试驱动开发（ATDD）这样的技术，它们在编码前根据用户故事和验收准则生成测试条件和测试用例，同时也验证、确认和检测用户故事和验收准则中的缺陷（见ISTQB初级敏捷测试大纲）。
测试设计
测试设计过程中逐步将测试条件生成概要测试用例、概要测试用例集合和其它测试件。因此，测试分析回答“测试什么”的问题，而测试设计回答“如何测试”的问题。
测试设计包括如下主要活动：
•设计测试用例和测试用例集并划分优先级
•识别所需的测试数据以支持测试条件和测试用例
•设计测试环境并识别任何需要的架构和工具
•获得测试依据、测试条件、测试用例和测试规程（参考1.4.4）之间的双向可追溯性
测试设计过程将测试条件逐步生成测试用例和测试用例集时，通常会使用各种测试技术（见第4章）。
与测试分析一样，测试设计也可能识别测试依据中类似的缺陷类型。同样，测试设计过程中识别缺陷也是一个重要的潜在收益。
测试实现
测试实现过程将为测试执行创建和/或完成所需的测试件，包括测试规程中测试用例的顺序。因此，测试设计回答“如何测试”的问题，而测试实现回答“运行测试需要的所有东西现在都有了吗？”的问题。
测试实现包括以下主要活动：
•开发测试规程并划分优先级，创建自动化测试脚本（如果有的话）
•根据测试规程和自动化的测试脚本（如果有的话）创建测试套件
•在测试执行进度表中安排测试套件以保证高效的测试执行（参考章节5.2.4）
•构建测试环境（包括测试用具、虚拟化服务、模拟器和其它基础设施），并验证所需的东西都已正确搭建
•准备测试数据，并确保它正确的加载到测试环境中
•验证和更新测试依据、测试条件、测试用例、测试规程和测试套件（见1.4.4节）之间的双向可追溯性。
测试设计和实现任务经常集成在一起。
在探索性测试和其它基于经验的测试中，测试设计和实现可能会发生在测试执行中，并记录为测试执行的一部分。探索性测试可以基于测试章程（测试分析输出的一部分），同时探索性的测试在它们设计和实现后立刻执行（参考4.4.2章节）。
测试执行
测试执行时，测试套件按照测试执行进度表的安排运行。
测试执行包括以下主要活动：
•记录测试条目或测试对象、测试工具和测试件的标识和版本
•通过手工或者测试执行工具执行测试
•比较实际结果和期望结果
•分析异常以找到可能的原因（例如：由于代码中的缺陷导致的失效，但也可能是误报[见1.2.3节]）
•根据观察到的失效报告缺陷（见5.6节）
•记录测试执行的输出（例如：通过、失败、被阻塞）
•作为针对异常采取的行动或者计划中测试的一部分，重复相关测试活动（例如：执行改正后的测试、确认测试和/或回归测试）
•验证和更新测试依据、测试条件、测试用例、测试规程和测试结果之间的双向可追溯性。
测试结束
测试结束活动从已完成的测试活动中收集数据，从而对各种经验、测试件和其它相关信息进行固化。测试结束活动发生在项目里程碑点，例如：软件系统发布时、测试项目完成（或取消）时、敏捷项目迭代完成时（例如：作为回顾会议的一部分）、测试级别完成时，或维护版本完成时。
测试结束包括以下主要活动：
•检查所有的缺陷报告是否已关闭，为测试执行结束时未解决的所有缺陷创建变更请求或者产品代办列表
•创建用于和利益相关者沟通的测试总结报告
•最终确定并归档测试环境、测试数据、测试基础设施和其它测试件，以便将来使用
•将测试件移交给维护团队、其它项目团队，和/或其它能够从中受益的利益相关者
•从完成的测试活动中分析经验教训，并确定在将来的迭代、发布和项目中的变更
•利用收集的信息改进测试过程的成熟度
1.4.3 测试工作产品
创建的测试工作产品属于测试过程的一部分。就像组织实施测试过程的方式存在显著差异一样，测试过程中创建的工作产品、工作产品组织和管理的方式，以及工作产品的名称也是千差万别的。本大纲主要遵循上面提到的测试过程以及在本大纲和ISTQB术语表中描述的工作产品。ISO标准（ISO/IEC/IEEE 29119-3）可以作为测试工作产品的指南。
本章节描述的许多测试工作产品可以在测试管理工具和缺陷管理工具中获取并得到管理。
测试计划工作产品
测试计划工作产品通常包括一个或多个测试计划。测试计划包括测试依据的信息，而其他测试工作产品通过可追溯性信息（见下面章节和1.4.4节）与之关联，以及在测试监控时用到的出口准则（或者完成的定义）。测试计划的描述见5.2节。
测试监控工作产品
测试监控工作产品通常包括各种类型的测试报告，包括测试进度报告（持续或者定期生成）和测试总结报告（在各种完成的里程碑点时生成）。所有测试报告应提供与受众相关的截至报告日期的测试进度细节，包括获得测试执行结果后的总结。
测试监控工作产品还应考虑项目管理方面的问题，如任务完成、资源分配和使用以及工作量。
本大纲第5.3节进一步解释了测试监控以及在这些活动期间生成的工作产品。
测试分析工作产品
测试分析工作产品包括定义并排好优先级的测试条件，理想情况下这些测试条件可以双向追溯到具体测试依据的条目。针对探索性测试，测试分析可能包括创建测试章程。测试分析也可能发现并报告测试依据中存在的缺陷。
测试设计工作产品
通过测试设计得到测试用例和测试用例组以覆盖测试分析识别的测试条件。设计没有输入数据和预期结果的概要测试用例，通常是一个好的实践。通过使用不同的具体数据，概要测试用例可以在多个测试周期中复用，同时确保测试用例的范围被充分文档化。理想情况下，每个测试用例可以双向追溯到它所覆盖的测试条件。
测试设计同时可以获得必要测试数据的设计和/或识别、测试环境的设计以及基础设施和工具的确定，尽管文档化这些结果的深度差别很大。
测试分析过程中识别的测试条件会在测试设计过程中得到进一步细化。
测试实现工作产品
测试实现工作产品主要包括：
•测试规程和测试规程中的执行顺序
•测试套件
•测试执行进度计划
理想情况下，一旦测试实现完成，就可以通过测试用例和测试条件，以及测试规程和测试依据中的条目之间的双向可追溯性，展示测试计划中制定的覆盖标准的实现。
在某些情况下，测试实现涉及使用工具创建工作产品或创建工作产品为工具所用，，例如服务虚拟化和自动化测试脚本。
测试实现也包括测试数据和测试环境的创建和验证。数据和/或环境验证结果文档化的完整性可能有很大差异。
测试数据用于确定测试用例的输入和预期结果的具体值。具体值加上使用具体值的明确指南，可以将概要测试用例转变成可执行的详细测试用例。在测试对象的不同版本执行时，同样的概要测试用例可以使用不同的测试数据。与详细测试数据关联的详细预期结果，可以通过使用测试准则得到。
探索性测试中，尽管探索性测试（以及对测试依据中特定条目的可追溯性）的文档化程度可能会有很大差异，但一些测试设计和实现工作产品仍会在测试执行阶段生成，
测试分析阶段识别的测试条件，可能会在测试实现阶段得到进一步的细化。
测试执行工作产品
测试执行工作产品主要包括：
•文档化每个测试用例或测试规程的状态（例如：准备运行、通过、失败、被阻塞、有意跳过等）
•缺陷报告（参考章节5.6）
•文档化测试过程中包含的测试条目、测试对象、测试工具和测试件
理想情况下，一旦测试执行完成，测试依据中的每个条目状态就可以通过与相关测试规程的双向可追溯性来确定和报告。例如：我们可以说哪些需求已经通过了所有计划中的测试，哪些需求存在测试失败和/或与之相关的缺陷，以及哪些需求还有计划中的测试等待运行。这些有助于验证否达到了覆盖标准，并能够以利益相关者可以理解的方式汇报测试结果。
测试结束工作产品
测试结束工作产品包括测试总结报告、后续项目或迭代的改进行动计划（例如：在项目回顾之后）、变更请求或产品待办条目，以及最终确定的测试软件。
1.4.4 测试依据与测试工作产品的可追溯性
如第1.4.3节所述，测试工作产品和它们的名称差别很大。正如上面所说，不管如何变化，为了实施有效的测试监控，在整个测试过程中，必须在测试依据的每个元素和与该元素相关的各种测试工作产品之间建立和保持可追溯性。除了测试覆盖率的评估，好的可追溯性还能支持：
•分析变更影响
•使测试可审计
•包含测试依据元素的状态（例如：通过测试的需求、测试失败的需求和延迟测试的需求），有助于提高测试进度报告和测试总结报告的易理解性
•以利益相关者可以理解的方式关联测试技术
•根据业务目标，为评估产品质量、过程能力和项目进度提供信息
有些测试管理工具提供了测试工作产品的模板，该模板与本节概述的部分或全部测试工作产品相匹配。有些组织建立自己的管理系统来组织工作产品并提供他们所需要的信息可追溯性。