• 首页
  • 心得
  • App质量管理优化方案 - 团队协作,流程控制

App质量管理优化方案 - 团队协作,流程控制

app优化.jpg

2016年5月27日,有幸被邀请参与云测主办的App质量管理优化方案

今天准备临时整理一下,分享出来

针对App开发过程中质量管理优化,一介布衣是以一个开发者的视角去看待整个流程,力求在需求开发,评审,研发,测试,发版等各个环节去控制自己的节奏,尽量避免在各团队衔接或者流程控制上影响app质量.

#团队目标

如何在规定时间内开发出符合质量要求的产品

代码质量把关

代码review

作为一种纯手工创造性劳动,每个工程师去 review 一下自己的代码,并不是"秀",起码对方可以知道对方在干什么,而且还可以用自己的思维模式去判断对方的代码实现是不是最优,有没有改进的地方. 这样在整个开发组里,大家互相知道互相在做什么业务. 对方的某个功能模块实现非常赞,是不是可以学习借鉴. 对方在一个代码实现上走了弯路,用我的方法可以事半功倍.

这样可以有效从代码层面把控一些缺陷.

服务器端单元测试

服务器端的单元测试脚本非常重要. 可以在第一时间发现服务器端 api 参数/响应 等错误. 尤其是在你数据结构改变,新增api 导致老api的异常. 一次单元测试执行,就是一次回归. 我们现在用 node.js 开发,相关node.js 下使用mocha 进行单元测试

这样对于服务器端调用接口做一个大致上的回归,有效把控代码质量.

git分支控制

  • 开发分支
  • 发版分支
  • 应急分支

git 的版本控制工具要充分利用好. 当你出现一些棘手的问题时,git能帮你更新有效版本,或者回滚到一个指定的版本. 一般开发过程中会对仓库做上面3个分支.

开发分支 所有的开发工程师在功能开发过程中,只允许提交代码到此分支.

发版分支 经过测试,回归等没有问题的代码发布到此分支上,并且同步到 应急分支.

应急分支 当发现线上分支出现问题时,需要紧急修复,可以直接在此分支上修改代码并测试,没有问题后再 merge 到 发版分支.

这样能有效避免 开发分支加入新代码而影响线上紧急bug修复.既不影响线上,也不影响线下开发.

时间的控制

开发团队在规定时间内完成预计的开发任务. 如何保证开发团队能按时按量完成开发任务:

  1. 需求前置 在开发2.0版本的是,已经把 2.1版本的需求全部罗列出来.

  2. 需求评审 对需求列表进行优先级高低评审,能不能对现有需求做减法.

  3. 技术评审 对评审完的需求,让技术团队做技术预估,各团队给出大致的开发时间. 也可以根据敏捷开发,对每个开发模块进行拆分 stroy ,然后依次给每个 stroy 按照难易度打分.

最后达到的效果: 就是在开发 2.0 的时候,2.1的需求文档,流程图,设计图 全部就绪.

测试团队要准备理解业务,与工程师有效沟通,反馈有质量的bug 如何做到?

1.测试团队一定要全面细致的理解产品需求. 2.在测试过程中一定要提交有质量的bug. 如果一个公司测试团队依靠测试工程师提交的bug数来做为kpi的话,往往出现提交一堆无关重要,甚至不是bug的bug. 相反,如果一个公司对上线后用户提交给客服的bug数量做为kpi的话,这样能有效杜绝这样的问题出现. 如果一段时间内,用户报告的bug数量越少,奖励测试工程师越多,这样是一个良性循环.

辅助手段

功能开关

  1. 上线的功能模块
  2. 第三方合作入口
  3. 甚至细微到某个菜单

都可以用功能开关来控制,尤其是类似第三方合作这样的入口,对方的服务能不能有效使用,会不会突然挂掉,停止合作等等. 如果有了功能开关,你可以在第一时间从服务器端关闭此入口,减少更多的损失.

原生页面开发 + H5页面搭配

一般对于营销类活动,常常采用H5页面来搭建. 一方面是可以服务器端控制 一方面这样的页面并不需要繁琐的客户端逻辑控制. 而且营销活动往往更换礼品频繁,活动规则层出不群. 甚至可以随时关停一个活动.

所以这样的营销活动页面用H5做非常合适.

出自:App质量管理优化方案 - 团队协作,流程控制



回到顶部