项目管理是一个繁杂的过程,每个阶段需要涉及到不同人员、资源的协调配合。每个角色都有自己的定位和任务,为了紧密配合项目经理或无分配项目经理运行项目的场景下确保项目成员共同达成项目目标,不同的角色掌握相应的项目管理意识就尤为重要。文章来源:https://www.toymoban.com/news/detail-637425.html
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线上崩溃原因,丰富稳定性测试脚本 -
CPU实时监控——记录稳定性测试期间对应版本的CPU占用数据,平均值、最大值 -
内存实时监控——记录稳定性测试期间对应版本内存占用数据,平均值、最大值 -
网络实时监控——记录稳定性测试期间对应版本流量占用数据,平均值、最大值
3.11 UAT阶段
UAT阶段应保障:
-
拉通主流程——根据项目/需求大小确定是否需拉通UAT,避免UAT因配置/环境等原因产生流程阻塞 -
跟进/复盘UAT问题——针对较大项目/需求跟进及复盘UAT中产生的问题,规避重复问题产生事项
3.12 上线前master回归测试阶段
master回归阶段需check:
4.1 风险程度分析
-
极小:没有危害或微小危害 20% -
轻度:轻度危害 40% -
中度:中等 60% -
重度:较大危害 80% -
极大:重度危害 100%
4.2 风险识别分类/分解结构
-
技术类:明确是否为需求/技术层面引起的风险 -
组织类:明确是否为项目依赖关系、资源等原因引起的风险 -
外部:明确外部影响具体原因
4.3 与协作方共同商榷风险推进方案
-
如为技术类风险——与项目经理、产品、研发共同评估技术层面解除方案; -
如为组织类风险——与项目经理、产品、研发共同协同调整计划/申请资源等方式处理; -
如为外部风险——测试人员需提供具体问题,协同项目经理、产品沟通具体原因,采取相对应的应对措施;
4.4 举例说明
4.4.1 举例一
产生问题:因测试周期时间紧,为避免延期提测,测试在研发阶段明确提测时间时,发现提测存在延期风险
-
风险程度分析及分类:组织类-重度风险
(识别阶段:研发阶段,识别及反馈角色:测试人员,类型:进度类) -
与协作方商榷推进方案(解决过程及方案):
因项目优先级较高,测试人员将此风险反馈至主产品及产品负责人处,因各方前期了解的信息存在差异化/关注点不一致等,线下拉齐会议沟通,根据交付优先级拆解交付内容,迭代提测进行测试,最终拉齐前、后端研发、测试交付目标一致,并调配资源进行各项任务交付,风险解除。
前置评估、高效协作
-end-文章来源地址https://www.toymoban.com/news/detail-637425.html
到了这里,关于测试角色在项目各阶段的项目管理tips的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!