【腾讯TMQ】有众测、不忐忑 ——记TBS内核测试优化之路

引言

随着TBS的迅猛发展,接入方越来越多。那么TBS内核发布时,如何在有限的时间人力下,合理评估对线上众多合作方版本的影响?来看看我们TBS测试是如何完成这项“不可能的任务”的。

先上个TBS三方下半年的测试效果数据:我们在测试人力投入不变的前提下,顺利完成4个TBS大版本的发布,有效保证了线上合作方的版本质量。

回首曾经——那些年的测试苦恼

TBS,即腾讯浏览服务 (Tencent Browsing Service) 的简称。

随着TBS的发展壮大,陆续有多家APP跟我们合作,发布了TBS版本的APP,使用TBS内核为其提供浏览服务。

那么问题来了,对于这些合作应用,在TBS内核发版时,我们如何确保各家的线上版本不受影响呢?

项目初期,我们采用的是“头部覆盖”方式,即重点对PV排名top的应用进行测试。在当时来看,由于接入个数不多,这种方案的效果还是不错的。但是随着越来越多的APP接入,下半年合作APP发展到上千家,总PV达到几亿。此时无论是三方个数还是量级,显然我们原有的“头部覆盖”方式已不能满足需求,而另一方面,线上非头部三方,因为TBS内核更新导致的问题扑面而来,让我们陷入了深深的苦恼。

更要命的是,通常定义,一个常规APP的“bug影响人数”是这个功能的统计人数,可对于TBS这种合作类产品,一旦出现线上问题,很可能对合作关系造成严重影响,“下架”成了我们不得不面对的问题。从某种意义上来说,我们TBS三方“bug影响人数”就是所有用户量。

于是我们TBS测试面临一个巨大的考验:每次TBS发版,高PV的好几十个三方APP都要测试到,以现有的时间和人力,怎么看都是个不可能完成的任务。

1、APP个数多。目前线上三方APP 上千家,其中重要的近百家 。在有限的时间人力下,如何确保这么多线上APP不受影响?

2、硬件覆盖度:机型、系统、各种网络情况 。如何对被测应用覆盖各种环境?

3、场景宽泛:某些应用场景很分散,比如购物类APP,包含的子页面不计其数 。如何覆盖到足够多的场景?

4、接入场景变更:线上版本的更新不可控,我们预知的TBS场景可能会随着合作方发版而有所变更。 如何实时更新TBS场景?

5、问题影响大:一旦出现问题会导致合作关系破裂,TBS被下架,PV严重受影响,尤其是PV高的合作方,伤不起。

初遇众测——可行性分析

企鹅众测,是基于真实用户测试的平台。众测团队接到移动APP研发团队的测试需求,一键发布众测任务,成千上万的用户同时帮产品做测试,并且覆盖全国各地用户,多种机型及网络环境。BUG探索、产品调研、数据收集、产品评测,四大类业务模块满足多种需求,多维度的用户信息帮助问题快速解决。

初遇众测,是被众测真实的用户群体所吸引。试想在TBS内核发布前,我们将无法覆盖的app以并行任务形式发放给众测用户,让他们帮助我们一起为内核质量把关,这样就能从时间和人力上减少发布风险,确保线上app质量。

有了这个想法,我们结合T实际情况,先从如何测TBS着手,反复思考最优方案,开始摸索TBS三方的众测模式。

一些方案的思考和落地,给同类型产品同学参考:

Q1:如何让用户共享到待发布内核?

解决方案:

设想1:在正式环境后台添加imei——风险较高,不可行 ;

设想2:参考宿主,扫码或网址方式添加内核——大部分三方没有入口,不可行 ;

设想3:使用Demo共享,由于Demo优先级最高,可以忽略其他影响。

Q2:TBS在终端是无法感知的,那么如何让用户有意识的去测TBS?

解决方案:

设想1:不区分,只要有问题都提上来——我们的核心目标是发现TBS问题,如果这样,审核成本过高而受益有限,不符合预期;

设想2:收集准确的TBS场景,告诉用户——合作版本的接入场景随时会变动,没法控制,不可行;

设想3:在内核打标识,比如下图的“网格线“”,以此通过页面渲染的展现效果,让用户方便的区分哪些页面跟TBS有关。这种偏主观的测试方式刚好可以发挥用户的能动性,达到测试场景充分的效果。

Q3:用户如何分辨反馈的问题是否跟TBS有关?

解决方案:最直接的办法是跟一个不接入TBS的合作版本对比,但是如何做到呢?

设想1:合作方重新打包不带TBS的版本供测试——对合作方依赖性强,不可行;

设想2:参考我们自己测试的办法,卸载本地共享到的宿主内核——用户操作太复杂,不可行;

设想3:,我们正好利用内核“可升不可降”的逻辑,只要保证被测demo包的版本号最高,那么卸载demo后三方只能使用sys,刚好与我们对比的条件符合。

联手众测——如何提测

1、发布策略

【策略一】头部应用的优先级划分:目前线上三方10W以上有近百家,我们对这些APP从“合作关系”、“PV量级”、“场景广度”、“金钱关联度”几个维度综合考虑,进行优先级划分。原则上优先级高的应用放在前期测试,最大程度减少发布风险。

(1)合作关系:不同合作方出现问题的风险是不同的。一般来说内部应用相对比较缓和,而外部应用由于自身利益考虑,对线上问题比较敏感,随时可能回退版本,下架TBS。因此,我们的策略是:合作关系越脆弱,优先级越高。

(2)PV量级:合作APP的使用人数,我们是通过上报监控来获取这部分数据的。一般来说,量级越大,说明使用人数越多,重要度也越高。

(3)场景广度:某些APP的接入场景很宽泛,涉及的页面特别多,单凭人工测试难以覆盖,可能存在遗漏导致的测试风险。

(4)金钱关联度:接入场景涉及购买、支付的APP,一旦TBS出现问题,会直接影响合作方KPI,处于对方角度,这类要特别小心。

【策略二】众测可操作性分析:我们将待轮询的APP,根据其特点,分别以“人工轮询”和“众测轮询”方式操作。经验上,功能型和游戏类APP,使用门槛较高(比如账号级别、基本使用规则等),因此我们列为“人工轮询”类。而大多数浏览型APP,偏向于页面浏览覆盖,用户上手成本较低,有一定趣味性,适合众测,我们归为“众测轮询”类。

这部分内容是比较通用的,一般来说不用发布前频繁更新,但要注意,社会热点、运营活动等因素影响下,某些APP的PV排名可能会有剧烈变化,比如前一阵直播比较火,虎牙直播的PV就突飞猛进上升到百万量级,测试要特别关注。

2、众测发布流程

第一步,进行发布前Check,准备好以下资源:

TBS demo网格线包:准备待测内核的demo包,要求内核渲染有网格线标识,方便用户识别 。

demo版本号检查:为了方便对比,demo包需要比线上内核版本号高,避免卸载demo后,共享线上内核,无法使用sys;

线上TBS场景review:检查待测线上版本的最新TBS接入场景,供众测用户测试参考;

准备相关截图:为了保证测试效果,需要对操作步骤截图指引;

确认反馈方式:本次测试的要求,如果有预埋上报log可不做要求,其他情况一般要提供截图、视频、或者logcat等信息,便于后期验证和跟进;

预期反馈描述:明确反馈问题类型,比如TBS三方主要是显示和功能问题,尽量避免需求建议吐槽等无关反馈;

设计反馈分类:要求用户对比sys,以此区分APP问题还是TBS问题,达到初筛的目的。

第二步,自助在众测官网提测。

众测发布入口tesly.oa.com/access 接口人:黄天化(化名)上传相关内容,我们就可以直接提交众测申请,等待发布了,提交成功后有邮件同步。

3、众测发布后关注

由于TBS的特殊性,线上APP版本有可能实时更新导致场景变化,如果出现,要及时修改任务内容(主要是TBS场景参考部分),避免众测用户扎堆反馈场景失效,干扰测试结果。

案例:2.4版本的墨迹天气,首页人物右侧的“红包”logo,点击进去是TBS场景,于是把这个场景写进提测内容,要求众测用户进行测试,但是任务发布后,墨迹天气的后台临时把这个场景去掉了,因此很多众测用户反馈找不到我们指定的测试场景。后来通过对线上任务的变更,修改了这个问题。后续我们提测时,也注意对不确定的场景不做指定,仅做参考。

收到众测反馈——如何审核

有意向使用众测的同学,可能最担心的一个问题就是“审核成本”。面对大批的众测用户反馈,如何在有限的时间内去找到我们最关注的内容?我们TBS通过持续的优化改进、以及众测同学的功能配合,已经小有成效。

1、审核利器

利器一:预分类设计

通过对提测任务时的分类设计,快速区分几大类问题,让用户帮我们找到重点问题。

始终无网格线:即调起问题,始终没有调起TBS,属于TBS的调起和加载问题 。

非网格线页面反馈:即APP自身问题,与TBS无关,整体优先级低。
网格线页面反馈,且卸载demo不存在:即TBS存在,sys不存在的问题。与我们的内核关系密切,优先级最高,重点验证 。

网格线页面反馈,且卸载demo也存在:即sys共有问题,优先级低,仅对严重影响体验的反馈做跟进,同步合作方。

利器二:军团的长期培养

“军团”是众测为长期任务培养的固定用户群体,也是众测服务的亮点之一 。

文档学习:我们结合TBS三方特点,以任务的方式对军团发布学习文档,并辅助以考题检验军团学习成果,提升TBS三方测试军团的TBS基础技能,从而提升反馈有效率,减少无效、无关反馈。

团长审核:要求团长对军团反馈的问题做验证和筛选,标注“重点关注”,减少我们的审核投入。

团长复现:团长用自己手机对重点问题做复现,二次确认复现概率
输出报告:团长汇总输出众测结果,给到提测方。

利器三:结果可靠性保证

我们通过以下几方面来保证众测结果的可靠性:

抽查制度:团长对测试结果抽样检查,一旦发现与反馈不符,有严格的惩罚机制 ;

用户星级:对用户TBS测试能力关联反馈质量,划分级别 ;

自动检测:以SDK形式嵌入APP中,自动收集用户的测试内容。目前未做,主要原因是合作方出于安全性考虑,比较难接受,后续打算在内部APP上做个尝试;

线上反馈重合度:正式发布后,结合线上反馈对测试内容进行review分析。

利器四:合理利用测试结果

反馈关联性:用户的反馈一定程度上反映了用户的实际使用场景,结合反馈问题的分布情况,强化某些TBS场景用例的测试优先级,建立“高危场景区”,有利于在有限时间抓住测试重点,更好的保障产品质量。

兼顾正向反馈:要求用户逐条反馈,其中也包括正向反馈,这样更合理的整体评估用户对单个场景的覆盖度。

内核能力风险评估:创建评估内核能力的7个维度:调起、显示、功能、搜索、下载、视频/音频、购买、,让用户基于从纯APP使用者的角度,发挥主观能动性,自选APP场景,整体评估TBS内核能力,更适合评估内核能力风险。

2、审核基本流程

第一步:通过预设分类,用网格线标识区分TBS相关场景、用sys对比方式排除系统问题,方便的筛选出真正和TBS有关的反馈,大幅提升测试效率。

第二步:团长验证,同步结果。要求帮派团长基于上述原则,对帮派反馈逐个进行验证,标注“重点关注”。

第三步:我们只要检查验证测试单里的最核心问题高效的完成众测任务。

审核原则:网格线页面的显示、控件功能,不关注需求优化 。

随机问题处理:严重影响体验的,先尝试优测同机型复现 http://utest.qq.com/,如果仍然无法复现,联系用户配合验证。

**
非网格线反馈**:仅关注闪退、崩溃等严重问题,其他不关注。

网格线反馈,卸载demo不存在的:重点验证,转tapd区。

网格线反馈,卸载demo也存在的:判定为APP自身问题,转合作方接口人跟进。

测试效果

可见,通过众测平台的利用,下半年我们在TBS三方测试人力不变的客观条件下,取得了了以下几方面效果:

1、 头部APP的覆盖:从原有的内核发布测试5个APP,发展到“三周轮询制度”,累积可覆盖31个头部应用,覆盖个数是上半年的6倍;

2、 硬件覆盖的提升:从原来人工测试覆盖3台机器,到下半年利用众测,可覆盖30种以上硬件;

3、 测试效率提升:上半年纯人工测试5h/APP,下半年通过任务发布的优化、审核方式的优化、以及军团的培养,成功减少到1.5h/APP,测试效率提升3倍以上;

4、 内核发布的风险评估:有轮询数据支撑,提前评估已知问题影响,更加可靠的评估发布风险;

5、 线上反馈减少:下半年没有出现因为内核发布导致的线上版本严重问题,头部应用反馈呈收敛趋势。

小结和展望

以上是我们TBS三方下半年测试的一些尝试和经验小结。目前还有一些优化方案在进行中,。

1、 合作方发版跟进:发布长期众测任务,帮派自主跟随合作方发版节奏,遇到问题反馈,以此避免合作方发版和线上内核的适配问题;

2、 自动化的结合:每日监控头部应用的核心场景,快速发现问题,解决问题;

3、 “TBS三方测试白皮书”的推广:目前先在帮派内部推广,加强用户TBS基础知识、标准化反馈排查流程,以此提升众测反馈有效率,减少测试后期审核投入。后续,希望能挂在TBS官网,作为指导文档,助力合作方自主接入。

最后,给和我们一样有发布前风险评估苦恼的小伙伴们做个推荐:

有众测、不忐忑! 众测,你值得拥有! http://tesly.oa.com

关注微信公众号腾讯移动品质中心TMQ,获取更多测试干货!

版权所属,禁止转载

你可能感兴趣的:(精准测试)