作者：京东物流 宋雪薇
1 前言
项目管理是一个繁冗的过程，每个阶段须要波及到不同人员、资源的协调配合。每个角色都有本人的定位和工作，为了紧密配合项目经理或无调配项目经理运行我的项目的场景下确保我的项目成员独特达成我的项目指标，不同的角色把握相应的项目管理意识就尤为重要。
那么，测试角色作为我的项目交付的品质把控者，具备相应的项目管理意识在我的项目的高质量、高效率交付指标上有着重要作用，如前置辨认品质危险、进度危险等。本文旨在梳理、议论测试角色在我的项目各阶段如何评估测试范畴及危险、前置裸露问题以及推动测试进度等项目管理事项，高效合作及交付测试角色产物，最终与我的项目各方独特推动达到高质量、高效率交付的指标。
2 现状及思考
在现有麻利迭代疾速交付模式下，针对某一需要 / 我的项目会拆分至各个团队，各个团队节奏及交付指标不完全一致，且无项目经理角色跟踪推动的状况下，存在后置与合作团队沟通确认事项，如：未拉齐依赖方排期、后期未辨认出改变零碎、需要 / 设计变更未及时同步相干方、无设计方案沟通导致提测内容不满足提测规范，等均可影响交付节奏。那么作为测试角色的咱们能够做哪些事件？
外围宗旨：高效沟通合作，提前思考后续阶段较容易影响进度、品质问题及危险点，裸露问题，前置沟通、评估及推动相干事宜；防止问题后置裸露在测试阶段；下一章节就让咱们来详谈各个阶段测试角色可提前关注事项，与各方高效合作独特推动解决的相干 tips。
3 详谈测试染指各阶段的项目管理 tips
3.1 需要评审阶段
软件测试的第一步就是需要评审，只有对软件需要做了精确、残缺的评审后，能力对接下来各种测试工作的发展做好根底，如需要评审了解偏差，前期很多测试工作都将会受到影响。
需要评审实现需理解哪些信息：
- 优先级——辨认我的项目 / 需要重点水平，优先级，以及冀望上线工夫状况（定位后续跟进力度）
- 需要背景——该需要基于什么业务背景革新（便于需要了解不偏差及后续测试阶段重点关注的外围指标）
- 改变范畴——评审改变范畴基于现有零碎是否有抵触、是否明确正当，是否影响其余零碎，也可关注下体验问题（防止后续开发测试阶段流程不通返工）
- 辨认改变 / 交互零碎——明确该需要是否波及其余零碎改变，辨认改变零碎 / 是否需配合联调零碎（辨认改变零碎前置协调拉齐相干零碎周期，防止后续阶段长期协调资源状况）
- 测试节点——软件须要进行哪些方面的测试，如功能测试、联调测试、回归测试、性能测试、稳定性测试、兼容性测试、平安测试等
- 测试环境——明确交互零碎是否反对测试环境联调（可前置协调 / 前置确定联调计划，防止后置沟通确定环境占用测试周期）
- 测试数据——依据改变范畴思考测试数据起源，辨认是否可外部闭环造数，是否可应用测试小工具
- 测试形式——可前置思考应用功能测试、自动化测试
- 测试人员——辨认测试干系人、明确主测试方（如重点项目 / 需要须要主测试状况）
3.2 设计评审阶段
设计评审为评估设计满足品质要求的能力，辨认问题及提出解决办法。设计过程中越早减少质量保证流动对最终设计成果的影响就越显著。目前较大我的项目 / 逻辑较简单需要 / 研发优化，均需研发输入设计评审文档并邀请测试参加波及评审。
设计评审时须要 check 的内容：
- 设计思路满足需要——联合需要背景及内容优先关注设计思路是否与需要评审阶段了解的有偏差
- 设计内容是否存在脱漏——评估是否存在脱漏性能
- 关注实现形式——实时、异步等解决形式对后续测试排期、形式及测试难度有参考价值
- 评估改变设计影响——基于原有零碎改变除本次需要批改内容是否影响原有性能，是需明确影响范畴，研发侧输入影响范畴
- 明确阶段范畴——依据需要是否存在拆解阶段交付，是需明确各阶段交付内容
- 交互方 / 依赖方实现形式——关注交互方 / 依赖方实现形式
- UAT/ 灰度 / 上线计划——依据上线个性，前置沟通 UAT/ 灰度 / 上线计划
3.3 排期阶段
排期阶段是项目管理中重要的一环，时常在此阶段会裸露一些危险，排期容易呈现两个问题，一是排期不合理，二是后续不能依照排期稳步推动，好的排期就要尽量避免这两个问题，那么测试阶段正当的排期就需尽可能多的参考该节点及之前节点我的项目各方提供的无效信息，全局评估、拆分工作交付，最终提供较正当排期。
输入测试排期须要思考的维度：
- 参考我的项目重点水平、优先级——是否优先级与已排期需要抵触，需参考优先级调整资源及排期
- 联合需要、设计参考及核查研发工时及排期、阶段交付内容——研发提供拆解后的工作排期是否正当（前置性能是否提前交付，依赖的工作是否有序等），测试根据研发排期工夫提供可并行 / 串行等较正当的测试排期
- 关注研发是否有联调排期——需保障提测品质，工夫紧工作重状况下是否压缩研发联调排期，可能影响提测品质及测试交付工夫
- 测试联调排期——测试输入联调周期需拉齐对接零碎排期（可协同产品沟通拉齐），防止长期协调联调工夫导致延期
- APP 排期——需确认实现形式为：原生 /flutter
- 明确计划是否存在变更——可再次明确需要 / 设计方案是否存在变更未同步状况
- 明确主测试方——如波及多方零碎，排期阶段可明确主产品、主研发、主测试方
3.4 测试用例编写、评审阶段
测试用例的编写必须根据需要文档，联合设计方案，确认所有以疑难点，笼罩所有性能需要点，跟进需要状况输入冒烟测试用例、性能测试用例、联调测试用例，思考业务实操场景，模仿用户场景串联流程保障测试内容的高笼罩。并在用例评审节点邀请产研参加评审，有序进行用例评审，确认疑难独特欠缺测试点并会后输入评审会议纪要。
测试用例编写、评审阶段须要留神的事项：
- 确认需要文档版本及规范——明确最新 PRD 版本（存在产研线下沟通后未同步测试状况，尽量避免），如有原型需明确原型及 PRD 内容形容不统一状况下如何发展测试工作
- 思考细节逻辑合理性及歧义形容——思考细节逻辑形容是否正当，PRD 形容存在歧义点需标注明确
- 蕴含充沛的异样测试用例——丰盛异样用例，防止异常情况下性能异样
- 辨认用户体验问题——提示信息是否明确、页面性能是否易用
- 业务范围和零碎设计维度补全用例——跟进需要及设计细化测试维度丰盛测试用例
- 测试数据、账号、配置等——辨认测试数据、账号及配置是否需协同方配合，是否可应用工具等晋升效率，如需全流程连通在该阶段记录
- 测试用例评审——与产研侧确认测试范畴、沟通疑难，评审用例设计的清晰度与合理性，优先级排定是否正当，是否笼罩了需要上所有测试点，用例是否具备很好的可执行性，用例的冗余解决机制，是否设计了短缺的异样测试用例，是否从用户的角度登程来设计用户应用场景和应用流程的测试用例，是否简洁、复用性强。
- 联调用例评审——输入交互场景与交互方评审，如为主测试，评审前串联整个我的项目 / 需要的流程场景用例，组织评审、明确测试数据、账号、配置等信息
- 用例评审会议纪要——记录待确认点及已确认点
3.5 编码阶段
编码阶段作为研发角色流动，通过编码过程来实现产品需要，此阶段的异样等需相干方知悉；
研发阶段需同步的信息：
- 需要 / 计划变更——是否存在需要 / 计划变更，是否及时同步至产品、测试侧
- 是否有提测延期危险——存在延期危险会压缩后续测试周期，需前置辨认并抛出
3.6 代码评审阶段
代码评审是研发全流程的工程实际之一，通过代码评审能够更好的保障产品质量和代码品质；可依据改变大小与研发侧沟通进行线上 / 线下等评审形式参加。
代码评审阶段需测验的规范：
- 慢 sql、空指针等——可无意识评审慢 sql、空指针等问题
- 业务逻辑——测试人员需关注是否有显著的逻辑谬误，改变是否遵循业务逻辑
- 补全回归用例——跟进改变范畴可辨认需改变影响原有性能局部，特地留神需确保主流程是否影响，补充回归用例
- 文档——提供新接口 / 批改接口是否有相应的接口文档更新保护
- 需要抵触辨认——关注改变范畴，辨认其余需要是否也存在改变该段代码问题，防止需要抵触
- 进步集体代码评审能力——学习研发针对代码评审的意见 / 倡议以及好的代码实现逻辑，便于问题更早的发现（以及代码编写标准、可读性、可维护性等）
3.7 冒烟测试阶段
冒烟测试是指在对一个新版本进行零碎大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，尽早发现较阻塞进度问题，提前辨认。
冒烟测试阶段重点关注的维度：
- 基本功能验证——优先验证基本功能是否可用，便于后续逻辑等较简单性能发展
- 主流程验证——优先辨认主流程问题，防止流程阻塞，妨碍测试进度，提前裸露流程问题及危险（形式根据我的项目 / 需要状况无效采取手工 / 自动化形式进行）
3.8 功能测试阶段（内部测试阶段）
功能测试阶段开始了大规模的测试工作，在此期间认真详尽的测试，
功能测试阶段外围把控的思维：
- 明确变更同步——针对测试阶段任何变更需同步至相干方，防止一方不知情
- 辨认需要抵触——独特测试需要，测试分支、需要相互影响
- 测试数据高效应用——剖析测试数据是否可验证多用例，高效应用测试数据验证尽可能多用例晋升效率
- 测试问题务必抛出——测试阶段发现的问题即便较小也须要抛出来提供给相干确认方确认，如无需更改则记录相干论断
- 探索性测试——探索性测试，可在测试阶段发现后期未辨认到的影响性能等
- 测试进度报告、危险抛出——针对工夫较长 / 较大需要、我的项目发送测试进度报告，裸露危险（辨认是否有影响进度、品质等危险问题，抛出问题，记录待确认问题及已沟通确认问题
3.9 联调测试阶段（蕴含研发联调、测试联调）
联调测试为了保障该需要 / 我的项目的所有改变场景下发的数据在全链路零碎下失常流转闭环，笼罩用户实在实操场景来确保我的项目 / 需要的交付品质。
联调测试阶段重视：
- 研发联调环节——再次核查波及零碎交互需要 / 我的项目，研发联调工作是否笼罩主流程测试点
- 联调场景验证——与全链路零碎进行联调测试验证，笼罩用户实在实操场景
- 补全联调场景——在联调阶段，可能存在场景笼罩不全状况，可有选择性理解上下游零碎逻辑，可笼罩补全联调场景，且针对接口及音讯尽量全的确保数据传输场景
3.10 稳定性测试（实用于 APP）
为保障 APP 端用户体验，APP 稳定性测试不可或缺，上线前针对上线版本进行稳定性测试已退出到 APP 测试流程中，日常针对 APP 稳定性随机测试也继续监控。
稳定性测试需监控：
- 解体率——监控阿凡达平台统计，剖析 APP 线上解体起因，丰盛稳定性测试脚本
- CPU 实时监控——记录稳定性测试期间对应版本的 CPU 占用数据，平均值、最大值
- 内存实时监控——记录稳定性测试期间对应版本内存占用数据，平均值、最大值
- 网络实时监控——记录稳定性测试期间对应版本流量占用数据，平均值、最大值
3.11 UAT 阶段
UAT 阶段次要为业务验收阶段，用户角色验收产研测交付内容，为确保 UAT 顺利进行，较大我的项目 / 需要测试人员有针对性进行主流程拉通测试可提前发现配置、环境因素所产生的问题，此环节可放慢 UAT 进度确保我的项目更高效交付（该阶段可依据我的项目诉求调整）。
UAT 阶段应保障：
- 拉通主流程——依据我的项目 / 需要大小确定是否需拉通 UAT，防止 UAT 因配置 / 环境等起因产生流程阻塞
- 跟进 / 复盘 UAT 问题——针对较大我的项目 / 需要跟进及复盘 UAT 中产生的问题，躲避反复问题产生事项
3.12 上线前 master 回归测试阶段
上线前 master 回归未确保长时间需要不上线分支及版本抵触等因素，上线以后进行 master 回归操作可无效确保公布内容运行稳固，保障品质。
master 回归阶段需 check：
- master 回归测试——回归上线性能主流程以及原有流程主流程，躲避测试分支与上线分支代码抵触等问题
4 裸露危险最终与合作方独特确定运作策略
在我的项目各环节已前置思考可能带来的危险，提前躲避、提前裸露，但并不能齐全保障，那么在裸露危险后，可参考危险水平剖析与分类定位，与我的项目各方高效合作，独特商讨解除危险的可行性计划以及后续运行策略。
4.1 危险水平剖析
- 极小：没有危害或渺小危害 20%
- 轻度：轻度危害 40%
- 中度：中等 60%
- 重度：较大危害 80%
- 极大：重度危害 100%
4.2 危险辨认分类 / 合成构造
- 技术类：明确是否为需要 / 技术层面引起的危险
- 组织类：明确是否为我的项目依赖关系、资源等起因引起的危险
- 内部：明确内部影响具体起因
4.3 与合作方独特商讨危险推动计划
测试人员可依据测试角度定位危险优先级，优先解决危险程度较高问题，且优先级较高风险需同步至下级知悉，必要时可采取降级等形式解决；
- 如为技术类危险——与项目经理、产品、研发独特评估技术层面解除计划；
- 如为组织类危险——与项目经理、产品、研发独特协同调整计划 / 申请资源等形式解决；
- 如为内部危险——测试人员需提供具体问题，协同项目经理、产品沟通具体起因，采取绝对应的应答措施；
4.4 举例说明
4.4.1 举例一
背景： 治理工作台我的项目（优先级 top1，交付工夫紧，开发工作量大）
产生问题： 因测试周期时间紧，为防止延期提测，测试在研发阶段明确提测工夫时，发现提测存在延期危险
- 危险水平剖析及分类：组织类 - 重度危险
（辨认阶段：研发阶段，辨认及反馈角色：测试人员，类型：进度类） - 与合作方商讨推动计划（解决过程及计划）：
因我的项目优先级较高，测试人员将此危险反馈至主产品及产品负责人处，因各方后期理解的信息存在差异化 / 关注点不统一等，线下拉齐会议沟通，依据交付优先级拆解交付内容，迭代提测进行测试，最终拉齐前、后端研发、测试交付指标统一，并调配资源进行各项任务交付，危险解除。
小结： 根据危险水平，可外部解除的疾速推动落地，需耗时较长 / 协调资源等需及时反馈至下级沟通，确保危险尽快解除落地。
5 总结
前置评估、高效合作
保障在前置阶段通过测试经验总结提前思考后续阶段会带来的影响，蕴含但不仅限于：信息不同步、影响范畴不明确、依赖关系不清晰等，前置无意识的辨认较容易影响进度、品质问题及危险点，并裸露问题，继而与相干合作方高效合作、评估及推动危险点解除，防止问题后置裸露在测试阶段甚至交付上线阶段。