App质量管理优化方案 - 团队协作,流程控制
文章目录
2016年5月27日,有幸被邀请参与云测主办的App质量管理优化方案
今天准备临时整理一下,分享出来
针对App开发过程中质量管理优化,一介布衣是以一个开发者的视角去看待整个流程,力求在需求开发,评审,研发,测试,发版等各个环节去控制自己的节奏,尽量避免在各团队衔接或者流程控制上影响app质量.
#团队目标
如何在规定时间内开发出符合质量要求的产品
代码质量把关
代码review
作为一种纯手工创造性劳动,每个工程师去 review 一下自己的代码,并不是"秀",起码对方可以知道对方在干什么,而且还可以用自己的思维模式去判断对方的代码实现是不是最优,有没有改进的地方.
这样在整个开发组里,大家互相知道互相在做什么业务.
对方的某个功能模块实现非常赞,是不是可以学习借鉴.
对方在一个代码实现上走了弯路,用我的方法可以事半功倍.
这样可以有效从代码层面把控一些缺陷.
服务器端单元测试
服务器端的单元测试脚本非常重要.
可以在第一时间发现服务器端 api 参数/响应 等错误.
尤其是在你数据结构改变,新增api 导致老api的异常.
一次单元测试执行,就是一次回归.
我们现在用 node.js 开发,相关node.js 下使用mocha 进行单元测试
这样对于服务器端调用接口做一个大致上的回归,有效把控代码质量.
git分支控制
- 开发分支
- 发版分支
- 应急分支
git 的版本控制工具要充分利用好.
当你出现一些棘手的问题时,git能帮你更新有效版本,或者回滚到一个指定的版本.
一般开发过程中会对仓库做上面3个分支.
开发分支
所有的开发工程师在功能开发过程中,只允许提交代码到此分支.
发版分支
经过测试,回归等没有问题的代码发布到此分支上,并且同步到 应急分支.
应急分支
当发现线上分支出现问题时,需要紧急修复,可以直接在此分支上修改代码并测试,没有问题后再 merge 到 发版分支.
这样能有效避免 开发分支加入新代码而影响线上紧急bug修复.既不影响线上,也不影响线下开发.
时间的控制
开发团队在规定时间内完成预计的开发任务.
如何保证开发团队能按时按量完成开发任务:
需求前置
在开发2.0版本的是,已经把 2.1版本的需求全部罗列出来.需求评审
对需求列表进行优先级高低评审,能不能对现有需求做减法.技术评审
对评审完的需求,让技术团队做技术预估,各团队给出大致的开发时间.
也可以根据敏捷开发,对每个开发模块进行拆分 stroy ,然后依次给每个 stroy 按照难易度打分.
最后达到的效果:
就是在开发 2.0 的时候,2.1的需求文档,流程图,设计图 全部就绪.
测试团队要准备理解业务,与工程师有效沟通,反馈有质量的bug
如何做到?
1.测试团队一定要全面细致的理解产品需求.
2.在测试过程中一定要提交有质量的bug.
如果一个公司测试团队依靠测试工程师提交的bug数来做为kpi的话,往往出现提交一堆无关重要,甚至不是bug的bug.
相反,如果一个公司对上线后用户提交给客服的bug数量做为kpi的话,这样能有效杜绝这样的问题出现.
如果一段时间内,用户报告的bug数量越少,奖励测试工程师越多,这样是一个良性循环.
辅助手段
功能开关
- 上线的功能模块
- 第三方合作入口
- 甚至细微到某个菜单
都可以用功能开关来控制,尤其是类似第三方合作这样的入口,对方的服务能不能有效使用,会不会突然挂掉,停止合作等等.
如果有了功能开关,你可以在第一时间从服务器端关闭此入口,减少更多的损失.
原生页面开发 + H5页面搭配
一般对于营销类活动,常常采用H5页面来搭建.
一方面是可以服务器端控制
一方面这样的页面并不需要繁琐的客户端逻辑控制.
而且营销活动往往更换礼品频繁,活动规则层出不群.
甚至可以随时关停一个活动.
所以这样的营销活动页面用H5做非常合适.