登录 个人注册 企业注册 杂志订阅 | 我的需求 | 下载专区 | English
首页 > 行业 > IT > 移动端迭代安排,你需要知道的几点

移动端迭代安排,你需要知道的几点

返回>

2017年07月10日    作者:卢跃    来源:微信公众号“ 网易杭研项目管理”

A-A+

  在风光的移动设备数的背后,是一个个产品辛苦的迭代进行产品的更新,让更多的用户能够在手机上获取更多的信息。笔者有幸跟进网易某个产品移动端快三年的时间,看着这个产品从小到大,本文主要与大家探讨下和web端相比,移动端的不同点以及这些不同点对于移动端的迭代安排有什么影响。


多端


  市面上目前最常见的是iPhone版和安卓版,其次有iPad版本和windowPhone版本。对于多个端而言,需求基本一致(除了一些渠道的特定要求比如AppStore需要做IAP功能等),所以对于测试而言,只要准备一份测试用例即可。


  由于各个端使用不同的代码语言在不同的系统上完成相同的需求,所以对于测试来说,需要在各端都进行完整的测试,这就导致了移动端的测试工作量会比web端多。


  笔者跟进的产品组同样也主打iPhone和安卓,笔者设计的排期是同一批测试完成一端的测试时另一端同期需求刚好处于提测状态,此时测试能够使用同样的用例紧接着测试另一端,这样能够保证对于各端来说都有相对足够的测试来跟进,确保测试周期不至于太长。


  举个栗子同一期的需求,iPhone端在6.1号提测,所有移动端测试一起测iPhone端,6.5号完成测试,而安卓端在6.5号提测,所有移动端测试在6.6号开始测安卓,6.9号完成测试。


  至于具体如何保证如上的这个配合,需要结合自身产品的相关因素(如开测人数比,开测工作量比等)。笔者所在的产品目前为15个工作日的迭代安排。


兼容性问题


  由于app是依托于手机系统执行的,不同的系统对于app的执行都可能会造成问题,因此在测试期间需要进行兼容性的验证。而对于安卓系统,由于不同的手机厂商基本上都会自己开发一套系统,而市面上形形色色的手机商家不下百来个,因此安卓的兼容性问题是个比较头疼的问题。


  即使同一个系统,也有存在不同的手机屏幕大小,比如iPhone7和iPhone7Plus,这个对于兼容性也会有不小的影响。


  幸运的是,网易有个兼容性测试实验室,因此在笔者跟进的产品移动端版本迭代中,测试完成第一轮测试后都会申请兼容性实验室进行兼容性测试。选择第一轮测试后的原因是此时提交给兼容性实验室测试的包在各个场景下相对都是通顺的,若不然一旦兼容性实验室测试遇到不通顺时,需要产品方的测试来跟进判断是否是bug等,这种一来一回的时间也是不容小觑的。


网络问题


  在web端,只要你在正常使用产品,就证明网络是没有问题的。但是在移动端设备上,这个就比较麻烦了。我们用指头算一算,wifi、2G、3G、4G、无网络、弱网络、wifi切换运营商网络、运营商网络切换wifi等等,真的很复杂。


  而基于手机的轻便性以及移动端网络高费用性,在很多情况下,对于类似于云阅读、云音乐、云课程等产品,一般都会具有下载功能,供用户在无网络情况下也能继续使用我们的产品。一旦支持下载问题,又会涉及到收费资料加密功能、设备内存不足等情况。从网络的特性牵扯出来的一系列的支持功能和异常特性,这个对产品的策划、开发、测试的能力挑战都是非常大的。


市面上多版本并存


  对于2C的产品,一个新版本通过渠道发布后,一般只会对用户做提示升级,而不会进行强制升级。而有些用户得到提示后也并不会马上进行升级,这就需要我们技术人员在进行研发时需要考虑老版本的兼容问题。在这个问题上,我们产品的技术人员基本上会有三种方案:


  对于指定版本号有指定小功能,且这个小功能对于原来接口逻辑不会有什么调整,则在该接口中通过增加if…else…来控制,这个的好处在于移动端不需要进行接口的调整,只需顺势发个版本号即可。


  对于指定版本号有指定功能,且这个功能对于原来接口逻辑有较大调整,则新开一个v2的接口(相对于老接口v1来说)来给新版本使用,确保老版本使用的接口不会有任何问题。相对于第一种方案来说,此方案的好处在于能够有效的避免安卓和iOS同需求但是不同版本号。


  若新增的功能的触发时机和内部逻辑有很大的区别,即功能重叠度很低的时候,则请求的链接都会进行替换。


  当然,其中关于功能的差异程度判断和具体使用哪种方案是移动端开发和服务端开发根据具体需求场景具体讨论决定的。


  如上所述,多版本并存,之于排期,还需要预留多版本兼容所导致的额外向上兼容开发和测试。


移动端对外发布前服务端要先上线


  移动端对于用户来说更多的是数据的展示,而服务端则是数据存储和逻辑判断的地方。因此服务端之于移动端来说犹如水之于鱼,有水后才能有鱼的存在。而服务端上线时间依赖于我们是否需要该版本申请苹果推荐。


  若申请苹果推荐,则我们可能(注意是可能)会提交testflight包给苹果,来加大被苹果推荐的可能性(注:苹果官方没有正式的说明或者保证),笔者所在的产品也有几次申请推荐,一般都会在正式提交AppStore前两星期左右提交testflight,这就要求服务端要在提交testflight包前需要上线。


  若没有如上情况,则笔者所跟进的产品线一般来说是服务端在完成测试前一天上线,确保次日版本顺利提交AppStore或者提交渠道。


提交AppStore或安卓渠道并非万无一失


  目前苹果用户唯一的下载渠道就是AppStore,安卓用户更多的是从各个渠道商上下载(如小米的小米商城、华为的华为商场、腾讯的应用宝、百度的百度手机助手等等),我们提交版本上去后,渠道方会审核我们的app,确定没问题后才会对外放出,因此提交之后还需要留心审核的结果。


  此处需要强调的是苹果的审核,一般来说对于有时间要求的版本,我所跟进的产品会预留7d的审核时间。虽然目前苹果审核效率普遍有很大提升,一般2d左右,但保不齐某个版本苹果一耽搁就是一周左右的时间。


发布之后出问题修改的代价较高


  当一个已发布的版本出现移动端Bug或者出现需求不满足要求时,如果要修复这类问题,基本上就需要在渠道上重新发个版本(之前iPhone版本还能通过热修复来不发版修复一些问题,但是这个技术也被苹果以安全隐患为由给禁掉了),而对于用户来说,只有更新到最新版的包之后才能享受到修复之后的效果,这对于用户来说代价是相当高的,因为很有用户可能因为这个问题,而不再使用你的产品。


  基于此类现象,笔者在自己跟进的产品上会进行以下两类的处理:


  在测试完成冒烟或者第一轮测试后,会邀请策划、交互、视觉以及需求方(如运营过来的需求)来进行走查,确保功能上满足自己的需求。在预发环境,通过上线申请邮件来约束策划、交互、视觉以及需求方再次核对功能的准确性是否达到自己的要求,并通过正式的邮件回复“确认”。


  对于安卓来说,我们会在正式发布各个渠道前,优先发布到自己的官网(此处需要注意该版本是否申请了某个或者某些渠道的首发,若申请了首发,则需要降级发布到自己的官网,因为首发渠道一定是该首发包第一个对外发布的渠道)。发布官网后一般在二三个小时左右就会有一些更新量,通过这些用户的使用情况可以观察app的crash等情况,从而进一步确保发布到渠道上的包的质量。


总结


  移动端的多种特性以及其复杂情况,十分考验着从事移动端方向的人员。然而,被移动端超大规模的用户群体所吸引,许多移动端产品如雨后春笋般冒出,大家都在追求着“快”的信仰,而只有真正理解移动端特性的团队,才能在“快”的路上稳健的向前。

责任编辑:王兴钊

标签:迭代
0
版权声明©
本网站所有内容版权归项目管理评论杂志社及相关权利人(本网站的资料提供者)所有,未经项目管理评论杂志社明确书面许可,任何组织及个人不得复制、转载、摘编本网站的内容,也不得在本网站所属的服务器上做镜像或以其他任何方式进行使用。凡未经许可擅自转载,均视为侵权行为,本网站将依法追究其责任。
热点:ppp    新能源    敏捷   
关于我们 - 广告服务 - 联系我们 - 诚聘英才 - 隐私声明 - 杂志订阅 - 在线投稿 - 下载专区 - 网站地图
项目管理评论 版权所有
有意与本刊合作者,请与项目管理评论联系。未经项目管理评论书面授权,请勿转载或建立镜像,否则即为侵权。
合作电话:010-58383379 E-mail:pmr@pmreview.com.cn 京ICP证13028000号-3
PMI, PMP, PMBOK and the PMI logo are registered marks of the Project Management Institute, Inc.

技术支持:原创先锋_北京网站建设