站在众人肩膀上做测试

2016-10-29 21:44:00

缘起

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

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 产品调研