站在众人肩膀上做测试

缘起

“人不仅要学会低头走路,还要学会抬头看路”，这句话告诫我们既要踏实做事，又不要走错方向。当我们从繁杂业务测试中抽身出来审视内外形势时发现，业务测试面临的挑战越来越大，主要体现在：

1、功能越来越多、用户场景路径复杂：手管插件数已经从4.0的20多个增加到6.5的40多个，这导致每个版本需要验证的功能越来越多。目前手管日活接近1亿，就算百分之一的产品BUG概率，也有上百万的活跃用户受影响。

2、产品定位在改变、产品不再单一：手管已从最初的纯工具走向平台，同时也在摸索商业化，也就是说产品BUG不再是单纯的用户体验问题，可能是涉及到收入的严重问题。同时，从2个平台型产品(手管、同步)发展到8个产品，产品线众多。

3、Android系统进化快、机型众多，难以覆盖：从2010年的2.X到2016年的7.0，在Android系统快速进化过程的同时，Android手机也分裂得非常厉害，因为手管不仅需要兼容从2.3到6.0系统，同时还需要兼容不同厂商的自定义ROM，所以必然需要满足不同机型需要。

4、灰度或用户群反馈质量不高：用户反馈不及时且积极性不高，并且需要定位或者再次复现和验证问题时比较困难，这导致线上问题经常都是无法复现。

5、没有用户体验性测试线上环境：想上一个新功能，但是不知道用户会喜欢A方案还是B方案，也不知道产品在用户中的口碑好坏；需要在线上环境对功能或性能方面跟竞品对比，但缺乏样本数据等问题一直困扰着测试人员。

虽然手管质量一向比较平稳(2016年上半年线上缺陷总数为3个)，但以上问题趋势还是带来沉重负担，导致日常测试工作量暴增，尤其是适配测试数量，测试效率也在下降，简而言之就是，活多(场景多、机型多、系统多、功能多，任务多)、人少(2016年上半年日均0.75个版本)。

引入众测

面对以上挑战，我们有没有好办法？

1、购买手机？再多手机也赶不上市场的变化，何况采购经费有限。

2、招人？人数越多管理成本增加，并且组织效率会更低，因此人海战术也是不可取；

3、自动化？自动化可能可以解决小部分问题，但短期来看机器不可能完全取代人，机器生硬、固定的场景没法替代人思维的灵活性。

4、加大灰度？灰度通常是选择符合这次版本功能或环境需求的用户群，但频繁灰度会导致用户频繁收到更新提示，对用户体验来说也是种伤害，并且反馈比较慢。

学过时间管理的同学都知道事情优先级的分类和安排，同样，作为测试人员，我们也应该聚焦在更有价值的事情上，比如测试分析、技术深度和广度的钻研、质量和效率的提升，而不是深陷救火式手工测试事务上。因此，我们考虑使用外部资源去提高重复或执行类手工业务的测试效率，并引入了品质中心内的企鹅众测服务，企鹅众测具备本地测试没有的几大优势：人多、机器多、环境多、主动性高(利益驱动行动)，众测目前在BUG探索（真人真机众测、机型适配、BUG复现）、产品调研（问卷调查）、数据收集（数据标注、问题库建设）、产品评测(竞品评测、竞品对比)多个业务上都做得比较成熟。

众测实践

手管从去年底开始使用众测，但是因为之前尚未认识到众测的价值，因此当时基本上都是用在集成测试阶段，并且用例简单，导致众测没有发现太多问题，众测价值也并未体现出来。

从今年5月份开始，因权限突破摸底的需要，我们重新认识到众测的价值，随后大家在这两三个月中挖掘了不少众测场景，也取得不错的效果，并且让众测成为手管业务测试不可缺的一环，有效地补充了业务测试在人力、物力上的不足，形成完整的测试工作流。

在众测的实践上，手管主要按照需求分析与挖掘、场景与用例准备、任务提交、数据分析与结果闭环四个步骤：

1、 需求分析与挖掘：

1.1 测试人员主导：

a) 常规系统测试任务：

在需求分析或需求评审阶段，测试人员会根据产品特性考虑是否需要众测，分析的纬度包括网络因素、外部环境异常(系统程序、第三方程序)、网络数据异常、机型相关、ROM版本相关、自身兼容性、软件兼容性、硬件兼容性、大数据相关等。

b) 权限摸底任务：

常规系统测试结果是可预期的，但是权限摸底类型就不可预期，这类型任务更多是摸清现状，提供结果给项目组做决策，比如目前很多厂家收紧了应用权限，导致手管部分核心功能受限，例如桌面浮窗被拒绝授权导致无法出现，严重影响手管的活跃度，但具体是哪些厂家或者机型/ROM做了对手管功能做了限制还不清楚，而且这类问题在数据上报后台也不一定能看得到，因为有些系统接口是没有返回值，无法判断某个权限是否拿到。因此需要对外部常用机型或者ROM进行权限摸底供后面决策。

1.2 产品人员主导：

经过之前小范围的宣传，目前手管部分产品人员也有了众测意识。他们意识到众测相比海投的用户调研会有更好的效果，因为用户在利益驱动下主动性会很高，而且任务还可以带上demo,百说不如一见。因此，产品人员在规划产品需求时也会提出调研需求，比如场景短信的调研就是产品和测试共同主导的一次众测，双方共同设计众测场景，1.5天内228名用户137个ROM，收集用户高质量建议88条，发现Bug29个，效果还不错。

2、场景与用例准备：

经过步骤一的测试分析后，测试人员大概知道哪些功能或场景需要做众测，随后就需要开始准备测试用例和场景了。这里的需要注意的是，如果是有固定用户路径的，那么测试用例应该尽量简单明了，并且有需要的话附上预期结果截图，因为外部用户可能是个小白，同时测试步骤尽量少用技术语言。

提供测试包时也要注意，如果需要复现问题最好加上详细日志，并把日志输出到SD卡，这样众测重现出问题时就有详细日志。

同时，开发也可以对测试包的版本号进行降级，以免被外部抓取到。

3、任务提交：

以前手管的众测任务基本上是通过邮件形式通知众测接口人，但是后来感觉有点重，而且交流不方便，因此目前基本上是直接RTX沟通，然后给Excel用例。这样也会给众测接口人带来很多的工作量，因此已建议后续众测使用任务系统，利于形成规范的任务统一流程。

4、数据分析/结果闭环：

众测完成后，众测接口人会整理并输出众测结果，测试跟进人需要跟进数据，比如功能验证效果、摸底情况、复现问题，或者产品评测效果，如果发现结果不符合预期则建议产品或开发进行优化，然后通过众测再次验证闭环。

实际效果

我们先来看看近两三个月的使用情况(FT：Feature Team)：

具体任务细节：

在短短两三个月内，企鹅众测已经为手管提供了近30次的众测服务，按每次任务的机型、测试ROM、涉及的测试用户数粗略估算，一个任务至少2人/天左右，那么众测在这两三个月内就节省2*29 = 58人/天，覆盖各个厂商上千款机型，包括国内TOP8的厂商，并且发现高达200款机型存在手管核心功能的权限限制问题。在产品质量上，发现闪退和其他机型适配问题50个，并累积发现集成后Bug 100多个。在产品调研上提供有价值的建议100多条。

目前，众测已承担了手管部分适配测试任务，有效补充本地机型、人力、环境的不足。在分工上，本地测试主要验证重点机型，众测验证线上大量机型，并且手管的众测基本覆盖了之前提到的四大类型，例如:

1、BUG复现：反XX适配异常、手管骚扰拦截Bug

2、BUG探索：管家集成测试、管家6.5奥运专题测试、提醒助手Bug探索、6.0权限管理适配、同步助手软件锁适配

3、产品调研：软件管理用户存量、榜单/游戏Tab推荐调研、WIFI资讯页面评测、场景短信调查、厂商场景XX调研

4、机型适配：摇一摇WIFI适配

5、权限/能力摸底：免费WIFI场景、辅助功能、通知栏图标、XX悬浮窗

6、权限摸底：WIFI悬浮窗权限、进程存活、辅助功能、新ROM监控尝试、悬浮窗栈顶突破验证

7、线上问题复现：相册管家备份失败、强制更新Crash复现

案例分享

1、 辅助功能名单摸底

需求挖掘：项目组偶然发现某款XX（不方便透露厂商）手机的辅助功能名单列表里没有手管，但其他机型没有发现这问题。虽然是偶然发现，但是因为辅助功能对手管来说很重要，尤其是目前ROOT权限占比越来越低的情况下，有些功能需要辅助功能才能使用。但辅助功能列表属于系统接口，没有接口可以查询是否有手管，上报数据也无法看到，项目组猜测手管被XX厂商加入黑名单，因此需要测试摸底。

为什么选择众测：因为本地测试机型有限，如果要去和XX厂商谈判需要充足的证据，需要大量线上真实用户来佐证。同时我们也想了解是否还有其他厂商也对手管做了限制，也需要线上用户的众多机型。

众测任务： 覆盖290款机型，其中57款机型直接将手机管家辅助功能拉入黑名单，主要表现在XX和YY两个厂商，直接影响了悬浮窗和小火箭的开启。

结果闭环：手管商务团队利用众测结果与XX厂商交涉，并成功解除名单限制，同时由众测回归验证通过。

2、 问题复现

2.1 Crash

需求挖掘：手管有个强制更新的功能，在灰度期间发现手管强制更新开关打开后，造成Crash率0.24%猛增到0.6%，但因为Crash日志有限，本地测试人员多次尝试但无法复现问题。

众测协助： 1天内对Bug进行复现，成功复现并提供详细日志，协助手管团队解决该问题，并验证通过。

2.2 严重问题

背景：根据线上数据显示，相册管家照片备份失败率10%，影响用户量很大，但内部测试一直无法复现问题，问题难以定位。

众测：召集专家问题对问题机型暴力测试，半天内复现问题、提供有效日志信息协助项目组解决问题并回归验证通过。

3、 产品调研与评测

3.1 产品调研

需求挖掘：短信作为手机的基础功能，对用户体验的把握至关重要；手管场景短信功跟手机机型关联性强，故手管产品希望对场景短信做用户调查。

众测：产品和测试人员设计测试用例，在做适配测试的同时提供给用户调研

1）提交场景短信有效建议88条和场景短信Bug29个。

2）全面摸清了Top10厂商在各个系统版本中，系统自带的短信提醒情况。

3.2 产品评测(用户体验测试)

需求挖掘：WIFI管家的最新2.0版本新增新闻资讯功能，项目组对这新功能的性能、流畅度、用户体验效果不清楚，为了避免发出去才发现问题，因此想利用众测提前发现问题。

众测：WIFI管家除了在内容吸引度上落后于竞品，其他四项指标(加载速度、流畅度、美观度)均处于领先位置。

结果闭环：项目组对新功能发布更有信心，同时因为众测用户已经对速度和流畅度进行了评测，也无需本地再投专人去做性能分析。

后续计划

1、固化众测流程：尝试将众测流程固化并加入到手管日常测试中，补充业务测试在人力和物力上的不足，实现各有分工和偏重，提升整体测试效率和质量。

2、丰富现有模式和探索新模式：目前主要是适配测试、权限摸底，但用户调研和BUG复现任务还比较少，属于尝试阶段，因此后续继续探索，尝试使用不同模式，并且结合部门产品后期重点(商业化)，加强用户可用性测试。

后记

手管的众测实践是因为大家觉得确实不错，并能提升测试效率的自发选择，以上数据来自多位同事的实践付出，包括爱美丽、亿富、CC、Kerry/卖肉、Better等，另外安东在场景和方案设计上也给了很多建议。