作者：京东物流 宋雪薇
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 总结
前置评价、高效协作
保证在前置阶段经过测验经验总结提早考虑后续阶段会带来的影响，包括但不仅限于：信息不同步、影响规模不明晰、依靠联系不明晰等，前置有认识的辨认较简单影响进展、质量问题及危险点，并露出问题，继而与相关协作方高效协作、评价及推动危险点免除，防止问题后置露出在测验阶段甚至交给上线阶段。
