验收测试方法建设

背景:

部门交付策略转变,大量任务由ODC团队完成,质量管控形式更加严峻,结合“20191014-1432首开专项” 验收失败的教训充当反面案例制定后续验收测试标准;
1、需求、设计文档不规范;设计人员分析遗漏不是专职设计,时间不充足;
2、ODC开发同事过程中反向推动能力不足;主要体现在有疑问的需求点未做进一步反向确认;
3、ODC测试人员能力不足、且测试时间严重被挤压;测试中受阻的用例,最后交付都没执行,32天的专项测试才4天
4、ODC测完后直接给同步测试包一线验收,一线反馈有明显页面报错的问题,共计20余个Bug
5、验收测试进入太晚,在一线同步测试时才进行验收,验收出来的问题较多导致交付节点未保住,且后面浪费更多的资源补救

验收测试标准:(与PM对接最近验收需求,知悉需求计划,规划测试提前进入需求)
1、需求合理性分析(进入时间:在前期需求、设计阶段进入,验收测试人员对需求做评审)
2、用例完整性分析;(进入时间:ODC测试人员编写完测试用例,评审用例,识别是否有场景遗漏,给出建议后跟 进其补充完整,同时标注出涉及主流程、核心逻辑的测试用例作为验收测试用例)
3、主流程或核心逻辑验收测试;(进入时间:ODC测试人员测试中、测试完成,在ODC测试人员测试过程中做随机 测试,ODC测试完成后执行验收测试用例)
4、补充:验收时发现Bug较多,需进一步细化颗粒度验收,推动PM倒扣工作量,执行完整的测试用例进行测试

结果:
验收策略转变后,对比两个需求来看验收的需求质量有了明显改善,进一步上报中台、专业线寻求帮助,希望有公司 层面验收测试标准出台
1、【20191014-1432】正荣集团-销售系统-首开项目信息登记:验收发现了17个Bug,而且有很明显的页面报错的 问题
2、【20191203-0391】正荣项目-重构成本-供方平台对接改造:验收发现了2个Bug

 

 

 

上一篇:.NET ------ 查询和识别js 脚本


下一篇:CSV文件格式