夜雨聆风
关于软件测试项目管理的这些,你得懂!
会议·推荐
2026第十五届中国PMO大会
2026第二届中国AI项目管理大会
2026第五届中国项目经理大会
2026第三届中国医药企业项目管理大会
目录
1、测试项目中的风险管理
2、测试角色在项目各阶段的项目管理tips
3、从懵懂新人到项目管理:我的测试职业晋升之路
一、测试项目中的风险管理
（Austin zhai）
前言
测试经理除了要管理产品线的质量保障和日常部门事务工作外，另一项比较重要的就是测试项目全流程的管理。
今天不聊整体的测试项目流程如何开展，而是想聊一聊在同行中比较高频出现的一个字眼：风险管理。
什么是风险管理
“风险管理是指如何在项目或者企业一个肯定有风险的环境里把风险可能造成的不良影响减至最低的管理过程。风险管理对现代企业而言十分重要。”
那么从以上的这句话去理解的话，首先风险管理适用与项目或者企业。这里的项目其实范围很广，哪怕只是一个简单的测试活动或回归测试都是可以适用于项目这个字眼的，如果结合自身公司或团队的做事风格与特点整理出一套基础的SOP并且分段规划好的话无论多小规模的测试活动都可以称之为项目。
其次，任何事情都有风险，只不过风险的大小是否在可接受的范围中。那么在一个有风险的环境中如何把风险出现后造成的负面影响减小到最低就是一个大家都需要思考的问题。相信很多的测试同学都听过风险管理这个概念，但实际在工作中的话可能会因为自己的职能范围或权限无法很好的掌握项目全局或测试活动的整体面貌，所以这里才会说风险管理是测试管理层的职责所在，如果一个测试管理连基本的风险管理也没办法做到位的话，其实他的部分工作是失职的，随着时间的推移，其中产生的风险导致的结果往往会让团队承担数倍的后果与负面评价。
如何进行风险管理
首先这里有个很重要的概念就是风险管理的核心管理对象是什么？很多实际工作的情况中，在项目的前期计划阶段，经验不多的管理者会把产生风险的原因本身纳入风险管理的范畴。粗看下来貌似没什么问题，但博主不推荐这么做的原因和项目前要确定测试范围是一个道理，如果过于在意产生的原因会让管理者的关注重心发生偏移。
举个栗子：测试同学经常会碰到项目中给与测试的时长不够或deadline无法撼动的情况，那么此时如果项目规划与资源分配的时候管理者做了两种不同的风险评估。
A：判断与分析测试时间不够的每个原因并预防，需求穿插没有收敛、功能模块逻辑复杂，研发时间延期、代码质量不足，反复冒烟、测试手段不足、测试资源不足、信息不同步等。基于以上的这些种种，如果想把原因作为风险管理的对象就会让项目变得难以开展，让管理者疲于奔命不说，还会造成项目成员对于项目的信心不足、长期负面心理暗示等尴尬境地。
B：针对预测到的测试时间不足的现状进行项目风险管理，基于项目前期排期与资源分配，已知测试对于本次迭代版本的测试时间不充足。针对这种即将发生的情况，那么本次开发与测试除了进行必要的时间扩充（加班）之外，严格的提测与准入标准、有重心的确保迭代版本的核心业务模块、及早的测试左移、以及利用现有测试用例开展不同部门之间的交叉测试都可以有效的解决测试时间不够的情况。
其实到了这里，还是会有测试同学不太清楚选A还是选B，我们接下来就一种国内大部分公司都有个情况在做一下说明。
博主之前遇到过很多测试同学都吐槽这个岗位在公司中的受到的“不公对待”，线上故障或Bug基本都会算在测试的头上，开发同学貌似也不用承担什么责任。其实这样的想法本身就有问题，一般来说测试在整个项目流程中本身处于最下游，线上有故障或Bug的话最先进行的一定是问题定位与修复工作，确保线上服务正常后再来进行定责与事后完善。有问题是团队的责任，不管是测试与开发的管理者亦或是开发与测试的执行者。其实这里的处理方式和风险管理是一致的，通过风险产生的不良影响或损失来进行对应的风险管理，预防与减少风险出现只是其中的一种，预防的对象不是产生的原因而是产生的现状；更多的是事后处理，我们都是通过产生某种问题来找到对应的原因，从而总结归纳出下一次不再犯同样类型错误的。之前定义的“一个肯定有风险的环境里把风险可能造成的不良影响减至最低的管理过程”，就是在一次次的预测——>问题出现 ——> 解决处理 ——> 问题消失的循环中完善起来的。总而言之将大部分的精力扩散至问题发生的所有原因，还是聚焦于问题产生后的现状再加之于解决完善，这里大家应该已经有了自己的答案了吧？
那么风险产生的原因就不重要了吗？当然不是，每一次的项目中产生的问题各不相同，原因也大相径庭。我们无需了解可能产生风险的每一个原因，但当风险产生的时候原因却是解决问题的最终本质。通过一次次的总结与实践，当项目开展的前期我们可以把产生风险的可能原因列出并标明会出现的阶段或时间点，有了预期和准备之后才能在最短的时间内把风险控制在可控范围内；另外每个风险可能产生的情况与后果都需要在项目前期做好明确的说明，哪怕不是很准确也需要做好告警，因为当风险真正出现的时候再来评估风险的影响往往会变得比较的被动，特别是线上回归阶段，测试项目的末期出现风险的成本远远要高于项目前期。最后测试项目中的每个节点也要明确好对应的负责人、具体时间点与阶段性输出物，当出现问题的时候可以用最小的成本快进行问题快速定位与解决响应，也方便在项目结束复盘时通过节点与输出物进行项目质量的判断与评估。
实施建议
1.当遇到项目前期一些可预见的风险时，将风险的现状、如果发生后可能产生的连带风险一并提出，方便团队对此做出评估与措施；
2.不要觉得写原因像甩锅，在出现问题时先自省是好事，但如果真的是其他团队导致的风险产生也要实事求是的将问题成因表述出来，以帮助整个部门提升项目的质量与口碑；
3.“测试准入标准”是个好东西，很多公司都提倡测试推动开发，提升整体研发质量，表面上看测试有点“吃力不讨好”，但实际上测试团队的地位与话语权也是靠这样慢慢的提升或巩固的，如果不“倒逼”开发提升自身的质量意识，代码质量不佳的提测版本只会让测试更痛苦，大量的精力浪费在一些低级Bug中，更不要提风险有多大了；
4.提前预测，提前预测，提前预测，重要的事情说三遍，道理说起来都很简单，但是做到准确的提前预测是需要在平时不断的积累，每一次测试项目过后作为管理者是否能将项目的节点与输出物做好总结归纳，提炼出问题成因并通过技术与管理手段完善以防掉在同一个坑里并不是一个特别困难的课题；
5.一口吃不成一个胖子，风险管理也是不是一蹴而就的。无论你是新手还是大佬，每个公司、每个业务线、都会有自己不同的问题存在其中，团队的磨合、技术的磨合、有时甚至是情绪的磨合都是风险出现的因素。我们没有精力对应每一个可能的成因，但是可以通过一次次的有效锻炼来达到相对较好的提升效果，不要怕出现风险，可怕的不是想不到风险何时会出现，而是风险出现后犹豫不决、唯唯诺诺的心态和不思进取、消极待事的态度。
最后，愿每一个测试管理者都能在自己的管理之路上走的更稳、更远。
————————————————
原文链接：
https://blog.csdn.net/weixin_38306507/article/details/126646466
二、测试角色在项目各阶段的项目管理tips
（原创 宋雪薇 京东技术）
设计评审为评价设计满足质量要求的能力，识别问题及提出解决办法。设计过程中越早增加质量保证活动对最终设计效果的影响就越明显。目前较大项目/逻辑较复杂需求/研发优化，均需研发输出设计评审文档并邀请测试参与涉及评审。
设计评审时需要check的内容：
1. 设计思路满足需求——结合需求背景及内容优先关注设计思路是否与需求评审阶段理解的有偏差；
2. 设计内容是否存在遗漏——评估是否存在遗漏功能；
3. 关注实现方式——实时、异步等处理方式对后续测试排期、方式及测试难度有参考价值；
4. 评估改动设计影响——基于原有系统改动除本次需求修改内容是否影响原有功能，是需明确影响范围，研发侧输出影响范围；
5. 明确阶段范围——根据需求是否存在拆解阶段交付，是需明确各阶段交付内容；
6. 交互方/依赖方实现方式——关注交互方/依赖方实现方式；
7. UAT/灰度/上线方案——根据上线特性，前置沟通UAT/灰度/上线方案。
2.3 排期阶段
排期阶段是项目管理中重要的一环，时常在此阶段会暴露一些风险，排期容易出现两个问题，一是排期不合理，二是后续不能按照排期稳步推进，好的排期就要尽量避免这两个问题，那么测试阶段合理的排期就需尽可能多的参考该节点及之前节点项目各方提供的有效信息，全局评估、拆分任务交付，最终提供较合理排期。
输出测试排期需要考虑的维度：
1. 参考项目重点程度、优先级——是否优先级与已排期需求冲突，需参考优先级调整资源及排期；
2. 结合需求、设计参考及核对研发工时及排期、阶段交付内容——研发提供拆解后的任务排期是否合理（前置功能是否提前交付，依赖的任务是否有序等），测试依据研发排期时间提供可并行/串行等较合理的测试排期；
3. 关注研发是否有联调排期——需保障提测质量，时间紧任务重情况下是否压缩研发联调排期，可能影响提测质量及测试交付时间；
4. 测试联调排期——测试输出联调周期需拉齐对接系统排期（可协同产品沟通拉齐），避免临时协调联调时间导致延期；
5. APP排期——需确认实现方式为：原生/flutter；
6. 明确方案是否存在变更——可再次明确需求/设计方案是否存在变更未同步情况；
7. 明确主测试方——如涉及多方系统，排期阶段可明确主产品、主研发、主测试方。
2.4 测试用例编写、评审阶段
测试用例的编写必须依据需求文档，结合设计方案，确认所有以疑问点，覆盖所有功能需求点，跟进需求情况输出冒烟测试用例、功能测试用例、联调测试用例，思考业务实操场景，模拟用户场景串联流程保障测试内容的高覆盖。并在用例评审节点邀请产研参与评审，有序进行用例评审，确认疑问共同完善测试点并会后输出评审会议纪要。
测试用例编写、评审阶段需要注意的事项：
1. 确认需求文档版本及标准——明确最新PRD版本（存在产研线下沟通后未同步测试情况，尽量避免），如有原型需明确原型及PRD内容描述不一致情况下如何开展测试工作；
2. 思考细节逻辑合理性及歧义描述——思考细节逻辑描述是否合理，PRD描述存在歧义点需标注明确；
3. 包含充分的异常测试用例——丰富异常用例，避免异常情况下功能异常；
4. 识别用户体验问题——提示信息是否明确、页面功能是否易用；
5. 业务范围和系统设计维度补全用例——跟进需求及设计细化测试维度丰富测试用例；
6. 测试数据、账号、配置等——识别测试数据、账号及配置是否需协同方配合，是否可使用工具等提升效率，如需全流程连通在该阶段记录；
7. 测试用例评审——与产研侧确认测试范围、沟通疑问，评审用例设计的清晰度与合理性，优先级排定是否合理，是否覆盖了需求上所有测试点，用例是否具有很好的可执行性，用例的冗余处理机制，是否设计了充足的异常测试用例，是否从用户的角度出发来设计用户使用场景和使用流程的测试用例，是否简洁、复用性强；
8. 联调用例评审——输出交互场景与交互方评审，如为主测试，评审前串联整个项目/需求的流程场景用例，组织评审、明确测试数据、账号、配置等信息；
9. 用例评审会议纪要——记录待确认点及已确认点。
2.5 编码阶段
编码阶段作为研发角色活动，通过编码过程来实现产品需求，此阶段的异常等需相关方知悉。
研发阶段需同步的信息：
1. 需求/方案变更——是否存在需求/方案变更，是否及时同步至产品、测试侧；
2. 是否有提测延期风险——存在延期风险会压缩后续测试周期，需前置识别并抛出。
2.6 代码评审阶段
代码评审是研发全流程的工程实践之一，通过代码评审可以更好的保障产品质量和代码质量；可根据改动大小与研发侧沟通进行线上/线下等评审方式参与。
代码评审阶段需检验的标准：
1. 慢sql、空指针等——可有意识评审慢sql、空指针等问题；
2. 业务逻辑——测试人员需关注是否有明显的逻辑错误，改动是否遵循业务逻辑；
3. 补全回归用例——跟进改动范围可识别需改动影响原有功能部分，特别注意需确保主流程是否影响，补充回归用例；
4. 文档——提供新接口/修改接口是否有相应的接口文档更新维护；
5. 需求冲突识别——关注改动范围，识别其他需求是否也存在改动该段代码问题，避免需求冲突；
6. 提高个人代码评审能力——学习研发针对代码评审的意见/建议以及好的代码实现逻辑，便于问题更早的发现（以及代码编写规范、可读性、可维护性等）。
2.7 冒烟测试阶段
冒烟测试是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，尽早发现较阻塞进度问题，提前识别。
冒烟测试阶段重点关注的维度：
1. 基本功能验证——优先验证基本功能是否可用，便于后续逻辑等较复杂功能开展；
2. 主流程验证——优先识别主流程问题，避免流程阻塞，阻碍测试进度，提前暴露流程问题及风险（方式依据项目/需求情况有效采取手工/自动化方式进行）。
2.8 功能测试阶段（内部测试阶段）
功能测试阶段开始了大规模的测试工作，在此期间仔细详尽的测试。
功能测试阶段核心把控的思想：
1. 明确变更同步——针对测试阶段任何变更需同步至相关方，避免一方不知情；
2. 识别需求冲突——共同测试需求，测试分支、需求相互影响；
3. 测试数据高效使用——分析测试数据是否可验证多用例，高效使用测试数据验证尽可能多用例提升效率；
4. 测试问题务必抛出——测试阶段发现的问题即使较小也需要抛出来提供给相关确认方确认，如无需更改则记录相关结论；
5. 探索性测试——探索性测试，可在测试阶段发现前期未识别到的影响功能等；
6. 测试进度报告、风险抛出——针对时间较长/较大需求、项目发送测试进度报告，暴露风险（识别是否有影响进度、质量等风险问题，抛出问题，记录待确认问题及已沟通确认问题。
2.9 联调测试阶段（包含研发联调、测试联调）
联调测试为了保障该需求/项目的所有改动场景下发的数据在全链路系统下正常流转闭环，覆盖用户真实实操场景来确保项目/需求的交付质量。
联调测试阶段注重：
1. 研发联调环节——再次核对涉及系统交互需求/项目，研发联调工作是否覆盖主流程测试点；
2. 联调场景验证——与全链路系统进行联调测试验证，覆盖用户真实实操场景；
3. 补全联调场景——在联调阶段，可能存在场景覆盖不全情况，可有选择性了解上下游系统逻辑，可覆盖补全联调场景，且针对接口及消息尽量全的确保数据传输场景。
2.10 稳定性测试（适用于APP）
为保障APP端用户体验，APP稳定性测试不可或缺，上线前针对上线版本进行稳定性测试已加入到APP测试流程中，日常针对APP稳定性随机测试也持续监控。
稳定性测试需监控：
1. 崩溃率——监控阿凡达平台统计，分析APP线上崩溃原因，丰富稳定性测试脚本；
2. CPU实时监控——记录稳定性测试期间对应版本的CPU占用数据，平均值、最大值；
3. 内存实时监控——记录稳定性测试期间对应版本内存占用数据，平均值、最大值；
4. 网络实时监控——记录稳定性测试期间对应版本流量占用数据，平均值、最大值。
2.11 UAT阶段
UAT阶段主要为业务验收阶段，用户角色验收产研测交付内容，为确保UAT顺利进行，较大项目/需求测试人员有针对性进行主流程拉通测试可提前发现配置、环境因素所产生的问题，此环节可加快UAT进度确保项目更高效交付（该阶段可根据项目诉求调整）。
UAT阶段应保障：
1. 拉通主流程——根据项目/需求大小确定是否需拉通UAT，避免UAT因配置/环境等原因产生流程阻塞；
2. 跟进/复盘UAT问题——针对较大项目/需求跟进及复盘UAT中产生的问题，规避重复问题产生事项。
2.12 上线前master回归测试阶段
上线前master回归未确保长时间需求不上线分支及版本冲突等因素，上线当前进行master回归操作可有效确保发布内容运行稳定，保障质量。
暴露风险最终与协作方共同确定运作策略
在项目各环节已前置思考可能带来的风险，提前规避、提前暴露，但并不能完全保障，那么在暴露风险后，可参考风险程度分析与分类定位，与项目各方高效协作，共同商榷解除风险的可行性方案以及后续运行策略。
3.1 风险程度分析
1. 极小：没有危害或微小危害 20%
2. 轻度：轻度危害 40%
3. 中度：中等 60%
4. 重度：较大危害 80%
5. 极大：重度危害 100%
三、从懵懂新人到项目管理:我的测试职业晋升之路
（原创 小熊 51Testing软件测试网）
晋升是我们职业生涯中所有的人都需要面临的，是我们人生中的大事，晋升是对我们努力工作的肯定和回报，但是晋升并不容易，有可能努力10年才升一级，这需要付出很多的努力和毅力。晋升这个过程我有很多的收获和体会可以和大家分享。
01
第一段：
2010年我毕业啦
没有像很多人那样怀揣着梦想进入上海，我是懵懂，不知道干啥的。我简单到只想找一份一人吃饱全家不饿的工作。
在招聘软件上搜软件测试海投得来了第一份工作，游戏测试，工资3000，我很开心，这是一份纯功能测试，但我每天都在想如何把测试用例写的最好，覆盖率最高，慢慢的我变成了部门写用例最厉害的那个人，此后领导不让我做手工测试了，就只写用例，其他的测试人员执行用例。
已经写到拿到需求读一句话，就知道要写多少条用例，如何覆盖，导致公司的需求评审变成了我个人的补充大会；
偶然接触到性能测试，此时我的内心开始骚动了，已经开始幻想，这要是学会了，换工作8000没问题吧。因为我急切的想要跳出写测试用例的这个牢笼，省略学习过程，已大致掌握了性能测试。
收获：
成为了那个写测试用例最厉害的人，掌握了性能测试
建议：
初级测试专研能够突出自己成绩的，能够见效快的。提升基础：抓包工具，接口测试学习
02
第二段：
没有如愿换到8000的工作，工资5000
但我还是很开心的接受了这份工作，虽然还是游戏测试，但涉及liunx系统发布，和游戏性能测试，性能报告，这份工作，能够让我学习到很多，所以我去了。
印象深刻啊，入职第一天距离下班还有10分钟，美美的准备收拾东西下班的时候。领导突然问我会不会linux命令…
我说：我不会，之前没用过；
领导说：只教一遍；
10分钟说完了，他准时下班走了；我更懵了，那么多命令一个没记住，咋办？认命地放下了我的包和我迈出去的半条腿，坐下来一遍一遍的翻着命令，写到本子上，地铁上来来回回的看；第二天刚到公司，刚坐下，领导就说：你把这个部署到linux机器上去，就昨天教你的；
此时，暗自庆幸，给领导露了一手（没翻小本本哦），领导很诧异的看着我说：你是这么多测试入职以来，教一遍就自己上手的，挺不错。开启了领导很关照我，大大小小的事情都给我做，我很崩溃啊，干了3年薪资大升级。
期间python这个语言开始崭露头角，都说适合干测试的学习，这又骚动了我的内心，开始自学python，小有成就，但无项目给我实践，被搁置；期间也学习了抓包工作，sql语句，接口测试等。
至此，我已经掌握了，抓包，sql，接口测试，接口自动化，python基础，我觉得我可以准备下一份的工作了。
收获：
技能得到提升，领导欣赏，薪资一直顶额涨薪，其他人都是羡慕嫉妒啊！
建议：
已经工作了2年以上的测试建议提示方向：接口自动化，推荐入门工具：postman，进阶：python自动化方向
03
第三段：
测试经理
公司在发展，测试团队慢慢发展到20+人，如何管理好测试团队？
①做技术，肯定要自身技术过硬，大家才会信服你，那就要展现技术能力。
我开始带教测试新人，传授功能测试的经验，抓包，接口测试用例等，开始在公司开展测试培训，效果显著；这个过程把我的测试基础又巩固了一遍，自己也得到了提升，补足了很多基础知识；
又自告奋勇接下公司自动化爬虫研究的英雄令，每天晚上独自一个人奋战到11点下班，连续半个月，把第一套python爬虫代码写完了，并完成测试接口全自动化开发，这完全得益于之前自学的python基础，在测试同事心目中的位置和领导心目中的也越来越高。
②技术能力有信服，还欠缺管理人员能力啊。
是不是需要学习一下人力资源管理方面的知识，于是报名参加人力资源管理的培训和考试，人力资源的知识，绩效管理知识等。
我又把学习到的绩效管理知识用在了我的技术部门，结果我设置的更贴合技术部门，从而推翻了人事部门设置的绩效体系，新的绩效体系，使整个技术部门绩效和人效提升了30%。
收获：
管理能力提升
建议：
进入管理阶段，一定要学习人员管理方面的知识，做了管理，就免不了要自己独当一面，例如研发团队的甩锅问题，如何处理，这是一个情商和智商的战场。
时隔6年，我又开始不满足只管理测试，想管理项目，于是又报名了敏捷管理acp的考试，加入了学生行列，再学习，再出发。
04
第四段：
项目管理的进阶
目前项目管理已经获取证书，开始接手公司的部分项目，大家平时在工作中想要什么一定要勇于争取，争取的前提是，你有这个能力去做到。
1、如您转载本公众号原创内容必须注明出处。
2、本公众号转载的内容是出于传递更多信息之目的，若有来源标注错误或侵犯了您的合法权益，请作者或发布单位与我们联系，我们将及时进行修改或删除处理。
3、本公众号文中部分图片来源于网络，版权归原作者所有，如果侵犯到您的权益，请联系我们删除。
4、本公众号发布的所有内容，并不意味着本公众号赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本公众号证实，对本文全部或者部分内容的真实性、完整性、及时性我们不作任何保证或承诺，请浏览者仅作参考，并请自行核实。