制定测试策略时，功能测试、非功能测试和静态测试回答的是不同问题，取舍依据是风险来源和所处阶段，而非在三者之间做一次性二选一。功能测试确认系统是否做对事，非功能测试确认系统在压力、安全、兼容等条件下是否仍然可用，静态测试则在代码或文档运行前发现缺陷。本文按风险分配覆盖重点、按缺陷发现成本安排投入顺序，并用准入准出条件把三类测试串成可执行的计划。
要点总览（TL;DR）
- 三类测试回答不同问题：功能测试验证业务行为是否正确，非功能测试验证系统在压力、安全、兼容等条件下是否可用，静态测试在运行前从文档与代码中找缺陷，策略取舍是分配比例而非三选一。
- 覆盖比例按风险来源决定：核心交易与合规模块以功能测试为主并叠加非功能测试，高并发与对外服务提高非功能测试权重，需求歧义多、模块复杂、历史缺陷集中的部分把静态检查前移。
- 投入顺序按阶段安排：静态检查前置到需求、设计与编码评审，功能测试随迭代推进，非功能测试在集成后至上线前的集中窗口执行，每类测试都写明可核验的准入准出条件。
- 资源不足时按风险优先裁剪覆盖范围而非取消整类测试，优先保留高风险模块的功能测试与静态检查，非功能测试可缩小场景但保留关键指标，裁剪代价需相关方确认。
- 落地时把三类测试放进测试计划、用例与检查项、执行记录和缺陷跟踪四个载体，ONES 可承载用例与需求任务关联、测试计划与迭代关联、未通过用例创建缺陷及测试报告生成。
三类测试各自回答什么问题
三类测试的差别首先体现在目标上。功能测试验证系统行为是否符合需求描述，输入、操作与预期结果之间的对应关系是它的核心对象；非功能测试验证系统在特定质量属性约束下的表现，关注响应时间、并发承载、安全边界、兼容范围等条件；静态测试不运行被测对象，而是通过评审、走查、代码检查等方式在制品中查找缺陷。三者共用同一套需求与设计输入，但验证的问题不同，因此不能互相替代。
验证对象和缺陷发现时机也随之分化。功能测试的对象是可执行的业务流程和功能点，缺陷通常在测试执行阶段暴露；非功能测试的对象是系统在特定条件下的整体表现，缺陷往往要到集成或接近上线的环境才显现；静态测试的对象是需求文档、设计说明、代码和配置，缺陷在编码与评审阶段就能被发现。发现越早，修复所需的返工范围通常越小，这也是静态检查值得前置投入的原因。
建立统一口径后，后续的覆盖比例与排期才有共同语言。下表概括三类测试在目标、对象与时机上的基本差异，作为全文比较的基准。
| 比较项 | 功能测试 | 非功能测试 | 静态测试 |
|---|---|---|---|
| 测试目标 | 验证系统是否做对事 | 验证系统在约束条件下是否仍可用 | 在运行前发现制品中的缺陷 |
| 验证对象 | 业务流程、功能点、接口行为 | 性能、安全、兼容性、可靠性等质量属性 | 需求文档、设计、代码、配置 |
| 缺陷发现时机 | 测试执行阶段 | 集成或准生产环境阶段 | 编码与评审阶段 |
同口径差异对照：风险覆盖与资源投入
把三类测试放在同一组维度下比较，能看清各自的投入结构。风险覆盖上，功能测试覆盖业务逻辑与流程分支，对需求理解偏差和实现错误敏感；非功能测试覆盖系统级质量属性，对容量、攻击面、运行环境差异敏感；静态测试覆盖代码规范、设计一致性和文档完整性，对逻辑漏洞和遗漏需求敏感。三类测试的覆盖范围有交叠，但主要失效来源不同。
执行成本与前置条件差异明显。功能测试需要可运行的环境和较完整的用例集，人员以业务理解和用例设计能力为主；非功能测试需要接近生产的环境、压测或扫描工具以及具备专项技能的人员，准备周期长；静态测试主要依赖评审流程和检查规则，工具与人员门槛相对低，但需要稳定的评审节奏和明确的检查项。结果可重复性方面，功能测试用例稳定后重复执行成本较低；非功能测试受环境影响较大，结果波动需要多次验证；静态测试结果依赖检查规则和评审人经验，规则固定后一致性较好。
| 维度 | 功能测试 | 非功能测试 | 静态测试 |
|---|---|---|---|
| 风险覆盖侧重 | 业务逻辑、流程分支、需求实现偏差 | 性能、安全、兼容、可靠性等系统级属性 | 代码规范、设计一致性、文档遗漏 |
| 执行成本 | 中等，随用例规模增长 | 较高，环境与工具准备占比较大 | 较低，主要消耗评审时间 |
| 前置条件与依赖 | 可运行环境、需求基线、用例集 | 接近生产的环境、专项工具、技能人员 | 评审流程、检查规则、参与人员 |
| 结果可重复性 | 较高，用例稳定后一致 | 受环境影响，需多次验证 | 规则固定后一致性较好 |
| 维护成本 | 需求变更时需同步更新用例 | 环境与场景变化时需调整方案 | 检查规则需随技术栈演进更新 |
表中未涉及具体工具选型、环境规格与人员配比，这些取决于项目实际条件，需要结合团队现状另行确认。对照表的作用是提供判断依据，具体比例仍要回到风险来源上决定。
按风险来源决定覆盖比例
决定覆盖比例的第一步是识别风险来源。从业务影响出发，先判断某个模块失效会造成什么后果：影响资金、合规或核心交易流程的模块，功能测试需要覆盖主要路径和异常分支；影响用户规模或服务可用性的模块，非功能测试的权重应提高；需求与设计本身存在歧义或频繁变更的部分，静态评审的介入价值更高。风险越集中、后果越严重的模块，越值得叠加多类测试。
需求变更频繁、逻辑分支多的项目，功能测试的用例维护压力大，此时应把部分检查前移：在需求评审和设计评审阶段用检查项发现歧义和遗漏，减少后期用例返工。性能、安全、兼容等质量属性诉求明确的系统，需要在策略中单列非功能测试的目标值和验证窗口，避免被功能测试挤占。代码与文档缺陷前移的判断依据包括：模块复杂度高、历史缺陷集中、多人协作改动频繁、外部依赖多，这些信号都指向加强静态检查。
| 风险信号 | 优先加强的测试类型 | 判断依据 |
|---|---|---|
| 核心交易、资金、合规相关模块 | 功能测试为主，叠加非功能测试 | 失效后果严重，需覆盖主路径与异常分支 |
| 高并发、大流量或对外服务 | 非功能测试 | 容量与可用性直接影响业务连续性 |
| 需求歧义多、变更频繁 | 静态测试前移，功能测试聚焦变更点 | 早期评审可减少后期用例返工 |
| 模块复杂、历史缺陷集中 | 静态测试与功能测试并重 | 代码与设计缺陷是主要失效来源 |
| 外部依赖多、集成点多 | 功能测试覆盖接口，非功能测试验证稳定性 | 集成失败与超时是常见风险 |
高风险模块的做法是叠加而非替换：静态检查保证设计与代码质量，功能测试验证业务行为，非功能测试确认系统级约束，三者共同构成该模块的验证闭环。覆盖比例不需要精确到百分比，但应在测试计划中写明每类测试覆盖哪些模块、达到什么程度。
按阶段安排投入顺序与准入准出
把三类测试放到时间轴上，顺序安排的基本逻辑是：静态检查前置，功能测试随迭代推进，非功能测试在关键节点集中。静态检查在需求评审、设计评审和编码阶段介入，以检查项和评审记录作为产出；功能测试跟随迭代节奏，每个迭代完成新增功能的用例执行与回归；非功能测试安排在版本集成后、上线前的集中窗口，触发条件包括架构调整、流量预期变化、新增外部依赖或安全要求升级。
每类测试都需要明确的准入与准出条件，才能判断能否开始和是否完成。准入条件回答“具备什么才能开始”，准出条件回答“达到什么才算通过”。条件应写成可核验的条目，例如用例执行率达到约定比例、遗留缺陷等级和数量在约定范围内、非功能指标达到目标值。下表给出可参考的清单结构，具体数值需结合项目约定确定。
| 测试类型 | 介入阶段 | 准入条件（示例） | 准出条件（示例） |
|---|---|---|---|
| 静态测试 | 需求、设计、编码与评审阶段 | 评审材料齐备、检查项已定义 | 检查项全部完成、问题已记录并分派 |
| 功能测试 | 随迭代推进 | 版本可部署、用例已评审、环境就绪 | 用例执行率达到约定值、遗留缺陷在允许范围 |
| 非功能测试 | 集成后至上线前的集中窗口 | 环境接近生产、目标指标已确认、场景方案就绪 | 各项指标达到目标值、问题已评估处理 |
资源不足时需要裁剪，裁剪顺序应遵循风险优先：先压缩覆盖范围而非取消整类测试，优先保留高风险模块的功能测试和静态检查，非功能测试可缩小场景范围但保留关键指标验证。裁剪的代价要写进计划，例如缩小非功能测试范围意味着上线后容量风险由监控和应急手段兜底，这一取舍需要相关方确认。
策略落地：计划、用例与缺陷如何被跟踪
策略要变成可执行的动作，需要落到计划、用例、执行记录和缺陷跟踪四个载体上。测试计划承载三类测试的范围、排期与责任人，静态检查以评审任务和检查项的形式进入计划，功能测试按迭代拆分用例执行任务，非功能测试以专项计划列出场景、环境和目标值。用例与检查项按模块和测试类型组织，便于按风险模块汇总查看覆盖情况。
执行结果与缺陷需要关联跟踪。功能测试未通过的用例应能直接生成缺陷并保留用例与缺陷的对应关系，缺陷在处理过程中保持状态可见；静态检查发现的问题同样进入缺陷或改进项流程，避免停留在评审记录中无人跟进；非功能测试的指标结果与问题记录关联到对应版本，作为准出判断的依据。评审与交接环节的状态记录要能回答“谁在什么时间确认了什么”，这是准入准出条件可判断的前提。
ONES 在测试管理上提供了承载这些动作的能力：支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；支持多维度概览测试计划并将用例分配执行人；未通过的用例可快速创建缺陷任务，缺陷在测试与研发团队间流转，并可自动生成测试报告；缺陷管理覆盖全生命周期并可关联至迭代。用例库支持通过不同方式导入用例并以结构化方式组织，同时提供自定义属性以适应不同场景。对于静态检查与非功能测试的专项记录，现有资料未说明具体承载方式，需要结合团队实际配置确认。
适配场景与选择建议
不同项目特征对应不同的组合方式，下表给出三类典型场景的建议，作为策略制定的起点。
| 项目特征 | 组合建议 | 注意事项 |
|---|---|---|
| 迭代频繁、需求变化快 | 静态检查前移到需求与设计评审，功能测试聚焦变更点和核心路径，非功能测试按版本节奏保留关键指标 | 用例维护成本高，需控制回归范围 |
| 质量属性要求高（性能、安全、兼容） | 非功能测试单列专项计划并明确目标值，功能测试保证业务正确性，静态检查覆盖安全编码规范 | 环境与工具准备周期长，需提前排期 |
| 遗留系统、文档缺失 | 以静态检查和代码走查补充现状认知，功能测试围绕关键业务流程建立基线用例，非功能测试先做现状摸底 | 缺少需求基线时，用例以实际行为为准并标注假设 |
组合方案确定后，建议先在小范围试点再推广。试点可选择一到两个高风险模块，按计划执行三类测试并记录准入准出条件的达成情况，观察缺陷发现分布和修复周期，再据此调整覆盖比例和排期。试点阶段需要进一步核实的未知项包括：非功能测试的专项计划与结果记录在现有工具中的承载方式、静态检查项与评审流程的集成方式、准出条件能否配置为可判断的门槛。这些事项确认后再扩大范围，可以降低策略整体返工的风险。
常见问题
项目刚开始、需求文档还不完整时，静态测试还有必要做吗？
有必要，但检查对象要调整。需求文档不完整时，静态测试的重点从“文档是否写全”转向“已写出的部分是否存在歧义、遗漏和相互矛盾”，用检查项在需求评审和设计评审阶段提出问题，比等到功能测试阶段才发现理解偏差更省返工。对于遗留系统或文档缺失的场景，可以把代码走查和现状梳理作为静态检查的补充，先建立对现有行为的共同认知，再据此编写功能测试的基线用例。需要注意的是，静态检查的产出应进入缺陷或改进项流程并分派责任人，停留在评审记录中无人跟进就失去了前移的价值。
非功能测试一定要在接近生产的环境做吗，能不能在功能测试环境顺带验证？
性能、容量、稳定性这类指标对环境和数据规模敏感，在功能测试环境顺带验证得到的结论参考价值有限，容易低估或高估真实表现。可行的折中是把非功能测试分成两层：在功能测试环境做初步摸底，确认场景方案、脚本和监控手段可用；在接近生产的环境完成正式验证并作为准出依据。安全与兼容性测试同样需要明确环境与范围，例如兼容性要列出目标浏览器、终端和版本组合。环境准备周期通常较长，应在测试计划中提前排期，避免被功能测试挤占窗口。
三类测试的准入准出条件写成什么样才算可判断？
可判断的条件要能被核验，而不是原则性表述。准入条件描述“具备什么才能开始”，例如版本可部署、用例已评审、环境就绪、非功能测试的目标指标已确认；准出条件描述“达到什么才算通过”，例如用例执行率达到约定比例、遗留缺陷的等级和数量在约定范围内、各项非功能指标达到目标值。条件中的数值需要结合项目约定确定，并写进测试计划由相关方确认。条件确定后，执行记录和缺陷状态要能对应到这些条目，否则准出判断仍会依赖口头确认。
资源紧张时先砍哪类测试，砍掉之后风险怎么兜底？
裁剪顺序遵循风险优先：先压缩覆盖范围，保留高风险模块的功能测试和静态检查，非功能测试可以缩小场景范围但保留关键指标验证。不建议整类取消，因为取消后对应风险没有任何验证手段。裁剪的代价要写进计划并让相关方确认，例如缩小非功能测试范围意味着上线后的容量风险由监控告警和应急预案兜底，静态检查缩减意味着部分设计与代码问题要留到功能测试阶段暴露，修复成本相应上升。把代价写清楚，比事后解释为什么出问题更有用。
三类测试的计划和执行结果在 ONES 里怎么组织跟踪？
ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；支持多维度概览测试计划并将用例分配执行人；未通过的用例可快速创建缺陷任务，缺陷在测试与研发团队间流转，并可自动生成测试报告；缺陷管理覆盖全生命周期并可关联至迭代。用例库支持通过不同方式导入用例并以结构化方式组织，同时提供自定义属性以适应不同场景。静态检查与非功能测试的专项记录方式，现有资料未说明具体承载能力，需要结合团队实际配置确认，再决定是用检查项、自定义工作项还是独立计划来组织。
