什么是测试策略？和测试计划有什么区别_千锋教育

01 测试策略 vs 测试计划：一个决定生死，一个决定效率

先看两个真实案例。

A团队，一个电商平台项目，测试经理花了两周写详细测试计划：谁测试、哪天测、用什么工具。上线当天，支付接口崩溃，用户无法付款。为什么？因为测试策略根本没考虑“支付是高风险的”，测试资源全铺在UI界面上。

B团队，同样是电商项目，测试经理优秀件事：识别风险。发现支付、库存、订单是三大高风险模块。然后才写计划：核心模块自动化覆盖95%，非核心模块手工抽测。上线顺利。

差别在哪？

测试策略是“做什么”——选测试范围、定测试重点、分测试层级。测试计划是“怎么做”——排时间、分任务、配资源。

策略错了，计划再完美也是白费。

看看数据。根据2023年软件测试行业报告，70%的测试项目延期，根本原因是测试策略失败——不是计划没做好，是方向错了。测试策略决定了测试的“骨架”，测试计划只是“血肉”。

测试策略的核心三问：

• ►测什么？（哪些功能、哪些场景）
• ►测多深？（单元、集成、系统、验收）
• ►用什么测？（自动化、手工、性能、安全）

测试计划的核心三问：

• ►谁来做？（人员分工）
• ►什么时候做？（时间节点）
• ►怎么做？（工具、环境、流程）

一个测试策略错误，可能导致整个测试方向跑偏。比如你决定“全部手工测试”，结果项目有1000个接口——手工测试需要3个月，自动化测试只需要1周。这就是策略失败。

02 测试策略的四个层级：从宏观到微观

测试策略不是一张纸，而是一个分层结构。我把它拆成四个层级：

优秀层：业务测试策略

• ►定义：基于业务价值确定测试重点
• ►输出：高风险模块清单、核心业务流程
• ►例子：支付系统，交易成功率是核心指标，UI美观度是次要指标

第二层：技术测试策略

• ►定义：基于技术架构确定测试方法
• ►输出：自动化覆盖率目标、性能测试方案
• ►例子：微服务架构，必须做接口自动化；单体应用，重点做集成测试

第三层：测试阶段策略

• ►定义：每个阶段测什么、测多深
• ►输出：单元测试策略、集成测试策略、系统测试策略、验收测试策略
• ►例子：单元测试覆盖核心算法，集成测试覆盖接口交互

第四层：测试类型策略

• ►定义：功能、性能、安全、兼容性等各类型怎么测
• ►输出：功能测试策略、性能测试策略、安全测试策略
• ►例子：金融项目，安全测试必须占30%资源

看一个具体案例。某银行APP项目，测试策略是这样定义的：

业务测试策略：转账、理财、贷款三大模块，风险等级高，需100%覆盖
技术测试策略：API自动化覆盖率80%，UI自动化覆盖率30%
测试阶段策略：单元测试由开发完成，集成测试由测试团队完成，系统测试全量执行
测试类型策略：功能测试60%，性能测试20%，安全测试20%

测试策略的颗粒度决定了测试质量的上限。

这个策略直接决定了测试计划怎么写。比如性能测试要20%资源，那计划里就要安排专门的性能测试工程师，分配2周时间。

03 测试计划的六个要素：把策略变成行动

测试计划是测试策略的执行层。它把“做什么”变成“怎么做”。一个完整的测试计划包含六个要素：

要素1：测试范围

• ►明确：测哪些功能，不测哪些功能
• ►输出：测试范围矩阵
• ►例子：登录功能全测，忘记密码功能不测（因为开发说后面版本才做）

要素2：测试资源

• ►明确：谁、用什么工具、在什么环境测
• ►输出：人员分工表、工具清单、环境配置表
• ►例子：张三负责支付模块，使用Postman做接口测试，测试环境为staging

要素3：测试进度

• ►明确：每个阶段开始和结束时间
• ►输出：甘特图或时间表
• ►例子：单元测试第1周，集成测试第2-3周，系统测试第4-5周

要素4：测试交付物

• ►明确：输出什么文档、报告
• ►输出：测试用例、缺陷报告、测试总结报告
• ►例子：每天输出缺陷日报，每周输出测试进度报告

要素5：测试风险

• ►明确：可能出什么问题，怎么应对
• ►输出：风险清单、应对措施
• ►例子：开发延期导致测试时间压缩，应对措施是自动化测试提前准备

要素6：测试准入准出

• ►明确：什么时候开始测，什么时候结束测
• ►输出：准入条件、准出条件
• ►例子：准入条件——单元测试通过率90%以上；准出条件——所有P0级缺陷修复

看一个测试计划的实际片段：

测试范围：登录、注册、商品浏览、购物车、下单、支付、订单查询
不测范围：后台管理、数据分析

测试资源：
- 测试人员：张三（支付）、李四（商品）、王五（订单）
- 测试工具：Postman（接口）、Selenium（UI）、JMeter（性能）
- 测试环境：staging（功能）、production（回归）

测试进度：
- 第1周：接口测试
- 第2-3周：功能测试
- 第4周：回归测试+性能测试

测试交付物：
- 测试用例（Excel）
- 缺陷报告（Jira）
- 测试总结报告（Word）

测试风险：
- 风险1：开发延期 → 应对：自动化测试提前执行
- 风险2：环境不稳定 → 应对：搭建备用环境

准入准出：
- 准入：单元测试通过率>85%
- 准出：P0/P1缺陷全部修复，P2缺陷修复率>90%

没有计划的策略是空想，没有策略的计划是瞎忙。

04 测试策略和测试计划的实战配合：一个项目从0到1

光说不练假把式。来看一个完整的实战案例：一个在线教育平台项目。

优秀步：制定测试策略

项目背景：在线教育平台，核心功能是直播、录播、题库、支付。

风险分析：

• ►直播：高并发、低延迟，风险等级高
• ►支付：资金安全，风险等级高
• ►录播：功能相对简单，风险等级中
• ►题库：数据量大，风险等级中

测试策略输出：

业务测试策略：
- 直播模块：100%覆盖，重点测试并发、延迟、中断恢复
- 支付模块：100%覆盖，重点测试金额计算、退款流程、安全校验
- 录播模块：80%覆盖，重点测试播放、暂停、倍速
- 题库模块：70%覆盖，重点测试数据导入导出

技术测试策略：
- 直播：性能测试（1000并发）、接口自动化（60%覆盖率）
- 支付：安全测试（SQL注入、XSS）、接口自动化（80%覆盖率）
- 录播：UI自动化（30%覆盖率）、功能测试（手工）
- 题库：接口自动化（50%覆盖率）、数据验证（手工）

测试阶段策略：
- 单元测试：开发完成，测试团队抽检
- 集成测试：测试团队完成，重点测直播+支付接口
- 系统测试：全量执行，每周轮询
- 验收测试：产品经理+测试团队联合执行

第二步：制定测试计划

基于上面的策略，测试计划如下：

测试范围：
- 直播、支付、录播、题库四个模块
- 不测：后台管理、数据分析（下个版本）

测试资源：
- 4名测试人员：1人负责直播，1人负责支付，1人负责录播+题库，1人负责性能测试
- 工具：JMeter（性能）、Postman（接口）、Selenium（UI）、Burp Suite（安全）
- 环境：staging（功能）、perf（性能）

测试进度：
- 第1周：接口测试（直播+支付+题库）
- 第2周：功能测试（直播+支付）
- 第3周：功能测试（录播+题库）+ 性能测试（直播）
- 第4周：安全测试（支付）+ 回归测试

测试交付物：
- 测试用例（TestRail）
- 缺陷报告（Jira）
- 性能测试报告（JMeter+Excel）
- 安全测试报告（Burp Suite+PDF）

测试风险：
- 风险1：直播并发测试需要1000并发，环境可能不支持 → 应对：联系运维提前准备
- 风险2：支付安全测试需要白盒权限 → 应对：提前和开发沟通获取代码权限

准入准出：
- 准入：单元测试通过率>90%
- 准出：P0缺陷0，P1缺陷<5，P2缺陷<20

第三步：执行与调整

执行过程中发现：直播并发测试时，1000并发导致服务器崩溃。测试策略立即调整：先做500并发，逐步增加，找到瓶颈点。测试计划同步调整：性能测试延长2天，功能测试压缩1天。

策略和计划不是写死的，是动态调整的。

最终项目按时上线，直播并发支持800人，支付安全零漏洞。这就是测试策略和测试计划配合的结果。

05 测试策略和测试计划的常见误区：避开这些坑

误区1：把测试计划当测试策略

很多测试经理写了几十页的测试计划，详细到每天几点几分测什么。但问他们“为什么这么测”，答不上来。这就是没有测试策略的表现。

误区2：测试策略一成不变

项目中期发现支付模块风险极高，但测试策略还是按照最初定的“自动化覆盖率60%”。结果手工测试漏掉了关键场景，线上出问题。测试策略必须根据风险变化动态调整。

误区3：测试计划太细或太粗

太细：每个测试用例都写进计划，导致计划本身比测试还复杂。太粗：只写“第1周功能测试”，资源分配、工具选择全不写，执行时一片混乱。

误区4：忽视测试风险

测试计划里写“风险：开发延期”，但没有应对措施。结果开发真延期了，测试团队只能干等。测试计划必须有风险应对方案。

误区5：测试策略和计划分离

测试策略说“性能测试占30%”，但测试计划里只安排了1个人做性能测试，时间只有3天。这就是脱节。策略和计划必须对齐。

测试策略是方向，测试计划是地图。方向错了，地图再好也没用。

总结

测试策略和测试计划是软件测试的两大支柱。测试策略解决“测什么、测多深”，测试计划解决“谁来做、什么时候做”。两者缺一不可。

记住：70%的测试团队搞混了这两个概念。他们花了大量时间写完美的测试计划，却忽视了测试策略。结果就是——方向错了，测试资源全浪费在低风险模块上，高风险模块反而漏了。

现在，打开你的项目，问自己两个问题：测试策略是什么？测试计划怎么执行？如果答不上来，你正在无效加班。