agoo-sdkv1.1.0已参与了主客的灰度,在闭关的这1个月里,大家很努力,很辛苦,感谢兰葩,不才以及项目团队的全力配合和支持,从开始发起SDK流程的建立,到SDK流程约定,参与友盟方SDK的流程讨论,合作流程建立,参与agoo团建,以及agoo-sdk1.1.0版本的负责测试,发布,收获了很多,下面是本人的总结:
1.流程方面
我所经历过的sdk产品,基于属于探索性的前沿产品,开始定下的需求到后面都是面目全非,而架构设计基本都是经历分散->重构后模块化->然后趋于稳定.所以,整个SDK测试在项目kickoff和发布时间确定的情况下,中间的过程就2个字"折腾",此次SDK流程,代码review,代码静态扫描,版本feature,打tag,测试是唯一产品发布出口,接入文档跟进等action都严格执行,由于新引进了gerrit工具的风险,花费在这上面的时间大概1天,以及处理umeng方的问题等原因导致提测时间延后,从预期的13日提测改为16日提测,但是直到16日代码一直在修改中,代码一直不能封版,其中一个app产生多个service问题是最block测试进度的主要问题,而且由于适配测试投入过早,没有达到预期效果,再者本次投入测试的备份,弹窗等功能,不随SDK一起发布,一定程度上造成了测试浪费,下次还需要重新投入,基于这些问题下个版本中需要改善的点:
1.项目计划,需求等都需要记录,版本规划需求,不能口头,且先过需求,在编码;
2.流程继续执行,重点解决block问题.
2.开发测试方面
agoo-sdk产品,淘系,umeng以及后续的合作方都需要该版本,所以配合产品的推广,一起可以做如下的事情:
1. agoo-sdk版本多,目前有3个已发布的产品,而且每个发布的产品还各有自己的特点有必要写一个总结的沉淀文档.尤其是核心模块设计,这个非常重要,否则新手过来,无从参考,浪费大家时间.
2.版本发布,在外部条件不可控,且发布版本满天飞的情况下,测试作为唯一的出口,release版本由项目组共同评估,由测试发测试评估报告后发布.
3. usetrack版本方面umeng和淘系尽量统一,每次版本发布需要明确使用哪个版本ut包,针对usetrack的验收重点关注uttid以及和agoo相关的点.
4.虽然maven仓库有最终版本,但是还是希望针对umeng,淘系,外部合作方有一个专门的jar陈列的平台.很容易区分.也统一了发布最终版本.
5.通过和umeng的沟通,外部方看重laterbug,新版本的feature,androidmainfiest.xml中权限,receiver,service说明,以及快速反馈解决问题,后续和外部合作方都可以借鉴.
6.适配自动化方面投入需优先,个人觉得,有计划安排写,新人进入可以先写自动化用例,后才熟悉业务.
7.单测是最有效的测试手段,这个做起来不会亏本的.
8.产品的沉淀,专业术语,入门指南,哪些稳定了就先写.
3.产品方面
这个我废话几句,Agoo是一个很好的产品,我很喜欢团队氛围,很舍不得,但是从测试角度来说,Later了21个问题,这个测试报告我都不敢发出来(正式release之前,需要修复一些问题),为什么Later的问题这么多,这些都值得测试和开发思考,说实话,有些方面我是真的降低了质量要求标准,总之,基础服务方尽可能未雨绸缪,相关的混淆,流量,电量,以及客户方各种问题,都是我们改善产品的目标.下期改版也可能大,后续agoo-sdk测试交接给@壮飞,我将支持mtop4.0的测试工作.感谢大家.
