维护测试计划与常规测试计划如何划分

维护测试计划与常规测试计划的划分，主要看测试对象处在哪个阶段、测试活动由什么触发。常规测试计划对应一次明确的新建交付任务，维护测试计划对应已上线系统的持续维护。两者共用范围、策略、资源、进度、准入准出等基本要素，差异集中在触发条件、范围界定、回归深度和节奏安排上。下面给出定义、划分标准、组成机制和适用情形，帮助在具体项目中判断该用哪类计划。

要点总览（TL;DR）

• 常规测试计划面向一次明确的新建交付任务，在测试开始前确定范围、策略、资源、进度与准入准出标准；维护测试计划面向已上线系统的持续维护，围绕变更请求、缺陷修复、回归验证与例行巡检安排测试活动。
• 划分依据有两条：测试对象处于新建交付还是存量维护阶段，以及测试活动由版本规划还是由变更请求、缺陷单、例行巡检触发。
• 边界模糊时以本次测试活动的主要交付目标为准，允许拆分：大版本升级中的历史缺陷修复可作为常规计划下的独立测试轮次，也可单独建立维护测试计划。
• 两类计划共用范围、策略、资源、进度、准入准出等要素，可用同一套模板，通过计划类型与触发来源字段区分，差异集中在回归深度、节奏与评审重点。
• 维护测试计划包含影响范围分析与巡检安排，回归测试只是其中一项活动；常规测试计划绑定具体交付任务，版本目标变化后需重新确认范围与准出标准。

维护测试计划与常规测试计划的定义

常规测试计划是针对一次明确的测试任务所制定的安排，典型对象是新版本发布或新功能上线。它在测试开始前确定测试范围、测试策略、所需环境与人员、进度安排、风险应对以及准入准出标准，回答“这次要测什么、怎么测、谁来测、什么时候测完、达到什么条件才算通过”。常规测试计划通常与版本规划或迭代节奏对齐，测试活动随交付任务启动，随交付完成而收束。

维护测试计划面向已上线系统的持续维护阶段，围绕变更请求、缺陷修复、回归验证和例行巡检安排测试活动。它同样包含范围、策略、资源、进度和准入准出，但范围的确定方式不同：维护阶段的范围来自“这次改了什么、可能影响什么”，需要先做影响范围分析，再确定回归范围与深度。维护测试计划的节奏由变更和问题驱动，可能按周、按发布窗口或按巡检周期滚动执行。

两类计划共享的要素可以归纳为五项：测试范围、测试策略与测试类型、环境与资源、进度与节奏、准入准出标准。共用这些要素意味着可以用同一套计划模板承载两类计划，差异体现在每个要素的填写依据上。例如范围一项，常规计划依据需求与版本目标划定，维护计划依据变更清单与影响分析划定。

划分边界：按测试对象阶段与触发来源区分

划分的第一条标准是测试对象所处的阶段。处于新建交付阶段的对象，包括新系统首次上线、新功能首次发布、大版本重构后的交付，适用常规测试计划；处于存量维护阶段的对象，包括已上线功能的缺陷修复、配置调整、小范围优化，适用维护测试计划。判断时看这次测试活动的主要目的是“验证新交付物是否达到发布标准”，还是“验证存量系统在变更后是否仍然正常”。

第二条标准是触发来源。由版本规划、需求排期触发的测试活动，归入常规测试计划；由变更请求、缺陷单、例行巡检任务触发的测试活动，归入维护测试计划。触发来源往往比阶段更能说明问题，因为同一个系统可能同时存在两类活动：季度大版本按版本规划走常规计划，版本内的紧急修复按缺陷单走维护计划。

边界模糊的情形需要一条处理原则：以本次测试活动的主要交付目标为准，并允许拆分。大版本升级中常混有维护内容，例如升级同时修复若干历史缺陷。可行的做法是把升级主体作为常规测试计划的范围，把随版本修复的缺陷回归作为该计划下的独立测试轮次或子范围，在计划中标注其维护属性；如果修复内容独立于升级、单独安排发布窗口，则单独建立维护测试计划。原则是让每项测试活动都有明确的归属计划，避免出现无人跟踪的测试任务。

需要说明的是，脚本编写属于测试执行准备，攻击技术与源码分析属于安全测试范畴，单份需求文档的质量评审属于需求评审与确认，这些内容都不构成划分两类计划的依据，也不在本主题的讨论范围内。

两类计划的组成与运行机制

常规测试计划的组成围绕一次交付展开，通常包括：测试范围（对应需求与版本目标）、测试类型（功能、接口、性能、兼容性等按需选择）、测试环境与数据准备、人员分工与资源、进度里程碑、风险与应对措施、准入准出标准。运行流程是：计划评审通过后进入用例准备与执行，执行中跟踪进度与缺陷，达到准出标准后输出测试报告，作为版本发布的依据。

维护测试计划的组成围绕变更与巡检展开，通常包括：变更清单（本次涉及的变更请求与缺陷单）、影响范围分析（变更波及的模块、接口、数据）、回归范围与深度（全量回归、模块回归或冒烟级验证）、巡检周期与检查项、发布窗口与回退验证安排。运行流程是：变更进入待测状态后评估影响范围，据此确定回归范围并排入最近的发布窗口，执行回归与验证，记录结果并关闭变更或缺陷。

对比维度	常规测试计划	维护测试计划
触发来源	版本规划、需求排期	变更请求、缺陷单、例行巡检
范围确定依据	需求与版本目标	变更清单与影响范围分析
回归深度	按版本范围安排，通常覆盖新增与相关模块	按影响范围分级，从冒烟到模块回归不等
节奏	随交付周期，一次性或按迭代	随变更与发布窗口，滚动执行
评审重点	范围完整性、资源与进度可行性	影响分析是否充分、回归范围是否匹配风险
结果记录	版本级测试报告，支撑发布决策	变更与缺陷维度的验证记录，支撑关闭与发布

两者在评审、执行跟踪与结果记录上的差异，来自上述组成的不同。常规计划的评审侧重范围是否覆盖需求、进度是否可行；维护计划的评审侧重影响分析是否充分、回归范围是否与变更风险匹配。执行跟踪上，常规计划按用例执行率和缺陷趋势跟踪，维护计划按变更与缺陷的验证状态跟踪。结果记录上，常规计划产出面向版本的测试报告，维护计划产出面向变更和缺陷的验证结论。

当计划需要与需求、迭代、缺陷联动管理时，可以借助测试管理工具承载这些关联。以 ONES 为例，其测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；支持测试计划的规划和执行，并可多维度概览全部测试计划、查看进度；未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，缺陷可关联至迭代。这些能力对应的是计划与执行、缺陷之间的衔接动作，具体到维护场景的模板与字段设置，仍需结合团队实际流程配置。

与相邻概念的区别

测试策略与测试计划容易混用。测试策略是较长期的原则性约定，说明组织在测试类型选择、自动化程度、缺陷分级、质量门禁等方面的取向，通常跨项目、跨版本稳定；测试计划是一次性的安排，针对具体测试任务确定范围、资源、进度和准出条件。策略为计划提供依据，计划是策略在单次任务上的落地。维护测试计划与常规测试计划的划分发生在计划层面，不改变测试策略的稳定性。

回归测试与维护测试计划是活动与容器之间的关系。回归测试是维护测试计划中的一项核心活动，用于验证变更未破坏既有功能；维护测试计划还包含变更影响分析、巡检安排、发布窗口协调等内容。把维护测试计划等同于回归测试，会遗漏影响分析和巡检这些前置与例行工作。

版本发布计划与测试计划管理的是不同对象。版本发布计划管交付节奏，确定哪些内容在什么时间发布、发布顺序与依赖；测试计划管验证安排，确定这些内容如何被验证、达到什么条件才允许发布。发布计划是测试计划的输入之一，测试结论是发布决策的依据之一，两者相互衔接但职责不同。

适用情形与常见误解

适用常规测试计划的典型情形包括：新系统首次上线前的验收测试、新功能模块首次发布、大版本重构后的整体验证、面向新客户环境的部署验证。这些情形的共同点是测试对象尚未进入稳定运行状态，需要一次完整的验证来支撑发布决策。

适用维护测试计划的典型情形包括：线上缺陷修复后的验证、配置参数调整后的回归、第三方接口变更引发的适配验证、按周期执行的例行巡检、紧急补丁的发布前验证。这些情形的共同点是系统已在运行，测试目的是确认变更安全、存量功能不受影响。

常见误解有三个。其一，认为维护测试计划等于只做回归。实际上影响范围分析和巡检安排同样是维护计划的内容，缺少影响分析会导致回归范围要么过大浪费资源，要么过小漏掉风险。其二，认为常规测试计划一次制定可以长期沿用。常规计划绑定具体交付任务，版本目标变化后范围和准出标准都需要重新确认。其三，认为两类计划必须用两套模板。两类计划共享范围、策略、资源、进度、准入准出等要素，可以用同一模板，通过字段区分触发来源和计划类型即可。

举一个划分过程的例子（演示情景）：某订单系统计划在下个季度发布会员积分功能，同时线上存在一个优惠券计算错误的缺陷需要尽快修复。团队为积分功能建立常规测试计划，范围依据需求文档划定，安排功能测试与相关模块回归，准出标准为用例通过率达到约定值且无严重缺陷；为优惠券缺陷建立维护测试计划，先分析缺陷影响的计算逻辑与关联页面，确定模块级回归范围，排入最近的发布窗口，验证通过后关闭缺陷。两项活动共用同一套计划模板，通过“计划类型”和“触发来源”字段区分，进度分别跟踪。这样划分后，积分功能的验证节奏不受缺陷修复影响，缺陷修复也不会因为等待大版本而延迟。

常见问题

一个版本里既有新功能又有线上缺陷修复，应该建一份计划还是两份？

按主要交付目标判断，并允许拆分。如果缺陷修复随版本一起发布，可以把新功能作为常规测试计划的主体范围，把缺陷回归作为该计划下的独立测试轮次或子范围，在计划中标注其维护属性；如果缺陷修复独立于版本、单独安排发布窗口，则单独建立维护测试计划。关键是每项测试活动都有明确的归属计划，避免出现无人跟踪的测试任务。

维护测试计划是否只适用于线上出问题之后？

不限于事后修复。维护测试计划覆盖已上线系统的各类维护活动，包括配置参数调整、第三方接口变更引发的适配验证、按周期执行的例行巡检，以及紧急补丁的发布前验证。这些活动的共同点是系统已在运行，测试目的是确认变更安全、存量功能不受影响，与是否已经发生故障无关。

两类计划共用一套模板，评审时怎么保证不混淆？

在模板中设置计划类型与触发来源字段，评审时按类型侧重不同内容：常规计划重点看范围是否覆盖需求、资源与进度是否可行；维护计划重点看影响范围分析是否充分、回归范围是否与变更风险匹配。执行跟踪和结果记录也按类型区分口径，常规计划产出面向版本的测试报告，维护计划产出面向变更和缺陷的验证结论。

维护测试计划中的回归范围应该怎么定，才能既不过大也不过小？

先做影响范围分析，再定回归范围与深度。分析变更波及的模块、接口和关联数据，按影响程度分级：影响核心链路或公共组件的变更安排模块级甚至全量回归，影响局部页面的变更可用冒烟级验证覆盖。回归范围与变更风险匹配即可，范围过大浪费资源，过小则可能漏掉风险。分析结论应写入计划，作为评审依据。

用测试管理工具承载这两类计划时，需要关注哪些衔接点？

关注计划与需求、迭代、缺陷之间的关联是否顺畅。以 ONES 为例，其测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；支持测试计划的规划和执行，并可多维度概览全部测试计划、查看进度；未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，缺陷可关联至迭代。维护场景下的模板与字段设置，仍需结合团队实际流程配置。