假如不是BAT，专项测试要怎样做？

其实这个话题对于身在 BAT 的我来说，是个难题。因为 BAT 对测试本身的投入力度，在行业内是走在前面的。一直在这个环境成长，可能会不理解其他小团队的痛。但是我意识到，必须写一篇文章，一方面是因为最近确实接触了一些腾讯系公司，了解了他们的测试现状，我觉得需要有所总结； 另一方面是希望自己透过这个文章有更进一步的思考，最终能给出一些可以真正帮助到测试行业内其他团队的意见。

心理篇

我在 QCon 北京上的演讲《手Q 专项测试最佳实践》中曾经提过，专项测试有资源类性能、交互类性能、稳定性、兼容性和安全性等等。但仔细想想，对于一个小团队，一个创业或创业初成的团队需要管那么多吗？不用，只要心中有概念， 并有对应保底措施即可。对于小团队来说，更重要的应该是打痛点，因为痛点是产品发展的最大障碍，具备极高的性价比。但是什么是痛点呢？表面上很多产品都知道自己的痛点，其实并非如此。在不了解用户反馈的情况下，说自己明白用户的痛点，并且创造产品需求的比比皆是。所以对于专项测试而言，第一步无疑是找痛点。

第一步是建设反馈系统，找痛点。这种反馈包括各种用户反馈的收集分析，各种专项数据的前段和后端的上报分析。有一些如听云、 OneAPM ， Bugly 其实已经有一些这种监控上报的能力，只可惜在用户反馈收集和分析上，暂时没见到对应的系统。所以在应用现有系统的基础上，可能还需要自建。那么，假如有了这些系统，帮助我们知道有多少用户遇到卡死， 实际 Crash 率是多少，多少用户说耗费流量，实际终端耗费流量上报结果是多少。这时，痛点自然就一目了然，未来能达成的目标也清晰可见，老板也许会更加清楚地了解问题的严重性，从而下定决心改善。

第二步是找底线和目标。我们有了反馈系统，知道了用户的实际情况，这时我们就需要根据数据让团队自上而下地明确底线和目标，从而提升后续团队合作的效率。目标可以是，Crash 率是多少不让发布，Crash 率是多少可以不 FIX, 切换界面底线是多少，百分之多少的用户的流畅度是多少，用户反馈的卡顿问题从 TOP10 问题剔除等等。

第三步是解决问题。有痛点有解决痛点的目标，我们就要行动，为了达成目标，解决问题。我们以及我们的平台需要具备如下三个能力：

第四步是回到反馈系统，展示效果。开发，测试忙活了许久，达成了效果，却没有展示，那就是错失了开发与测试形成信任关系闭环的最佳时机。当然也缺失了进一步改进，做就精品的机会。就如我们的上传图片，一开始的目标仅仅是提高成功率，然后就是让带宽好的传输速度更快，再后就是让网络差的也能在保证成功的基础上再快点，再想办法搭救更多的在演唱会时发送不出消息和图片的用户，一路上都是不断地看数据上报，分析，解决问题，展示效果，再分析，再解决，再展示效果，形成闭环。

工具篇

一般来说，用户最痛苦的专项问题，通常是最表面和直观的问题，包括：

闪退：包括 CRASH，系统强杀，ANR，直接影响用户的使用。

卡顿：包括丢帧，动画帧率低，相应用户操作速度慢，甚至是卡死，但却没有触发 ANR 或者 watchdog timeout。这些给用户的感觉就是用得不爽，尤其是有对比的时候。

流量大 / 速度慢：移动应用必然面对流量问题，我们至此为止都会看到月末时候的流量效应，就知道这个的重要性。况且对于小公司来说，更痛的可能还是带宽，CDN 的费用问题。

弱网络兼容差：用户面向的网络情况其实是时好时坏的，但是用户期待业务能执行成功，哪怕多耗费一点时间。

待机时间短 / 手机发烫：自 IPHONE 开始，每个手机都需要“吊盐水”（使用移动电源）。如果他发现你在耗电排行榜 TOP1, 却一直在后台毫无建树，相信用户会好不犹豫地删掉。

业务专项问题：不同的产品有不同的业务专项问题，单独说出来是因为前面 4 个是通用的，请大家不要限制自己的思维。根据业务特质还有一些专项的指标会产生，例如地图应用定位的准确性，广告能力推送的准确性，音乐软件播放的音质，图片应用图片的质量。

下面针对这些问题，我们来看下我们有什么工具可以帮助到我们。没有像 BAT 这样的资源投入，但是问题还要解决。下面小 V 给大家推荐一些跟我们内部的建设思路近似的外部开源工具来帮助大家解决问题。（PS: 我只推荐我认为落地成本低产出最高的工具给大家，所以有些工具我不是不知道，而是投入的问题。并且下面我不再说专项指标，我会说是痛点，因为专项指标肯定不只有这些。下面的内容我尽量客观，但是不排除有一些主观判断，毕竟我没有每个都深入使用。）

Android

痛点

工具名

推荐原因

工具类别

落地优先级

落地成本

卡顿

Chrome for android 开源性能测试工具（surface_stats.py）

里面已经涵盖了 FPS 和 janky 采集的方法，用 python 写的命令行，简单直接地跟自动化测试结合。

发现

P0

低

[卡上报（AnimationPerfMon.java）](https://github.com/criswonder/droid-ski/)

在空间落地卡上报，跟处理 crash 一样，通过堆栈快速定位解决问题, 补充 ANR 的缺失

发现 + 定位

P0

中

[听云](http://demo.tingyun.com/mobileApp/7155/interaction)/[OneAPM](https://mobile.oneapm.com/mobile/app/800/interaction#/measurementname/65914)

基于 UIThread/ 主线程的监控，都有不错的卡顿的发现能力。但是因为没有获取堆栈，而只有简单的方法名和 activity，所以对于复杂的软件定位稍微困难。

发现 + 定位 (弱)

P1

低

[Fresco](https://github.com/facebook/fresco)

通过内存缓存的优化达到流畅的图片及列表展示性能

解决

P1

低

[Realm](https://github.com/realm/realm-java)

通过更优秀的 I/O 性能，降低 APP 对持久化数据读写的损耗，从而提升交互性能。可替代 sqlite。

解决

P1

中

闪退

LeakCanary

高效率发现大部分内存泄漏导致的 OOM。

发现 + 定位

P0

低

[Bugly](http://bugly.qq.com/)/ 听云 /OneAPM/Testin

CRASH 监控的能力大同小异，都能对数据上报的统计分析，清晰现网情况，用户痛点。但我会推荐腾讯的 BUGLY, 因为 ANR, CRASH 都能提供比较足够的信息定位问题，另外，因为是腾讯的。

发现 + 定位 + 反馈上报

P0

低

[Testin](http://testin.cn/)

兼容性 / 稳定性测试利器，关键是机器的量够!

发现 + 定位

P0

低

待机时间短

Chkbugreport

从用户手机中提取 BUGREPORT。通过这个工具是可以分析简单的耗电问题，如 sensor 或摄像头没有关闭，wakelock 的问题。

发现 + 定位

P0

中

         **IOS**

痛点指标

工具名

推荐原因

工具类别

落地优先级

落地成本

卡顿

FastImage

通过节省 decode 的耗时等方法，提升图片及图片列表的展示性能

解决

P1

低

[Realm](https://github.com/realm/realm-cocoa)

通过更优秀的 I/O 性能，降低 APP 对持久化数据读写的损耗，从而提升交互性能。可替代 coredata,userdefault,sqlite。

解决

P1

中

[MGWatchdog](https://github.com/maxgordeev/MGWatchdog)

实现类似 ANR 的机制，主要是要跟上报结合

发现 + 定位

P0

低

闪退

Infer

解决因内存泄漏导致的内存耗尽导致的闪退。能扫描简单的循环引用导致的内存泄漏。

发现 + 定位

P0

低

[Bugly](http://bugly.qq.com/)/ 听云 /OneAPM/Testin

CRASH 监控的能力大同小异，都能对数据上报的统计分析，清晰现网情况，用户痛点。但我会推荐腾讯的 BUGLY, 因为 ANR, CRASH 都能提供比较足够的信息定位问题，另外，因为是腾讯的。

发现 + 定位 + 反馈上报

P0

低

待机时间短

iOSDiagnostics

可以获取一些耗电的模块的信息，如果可以融合到数据上报中的话就更好了。

发现 + 定位

P0

中

通用

痛点指标

工具名

推荐原因

工具类别

落地优先级

落地成本

流量大 / 速度慢

BPG （android，类似 webp）

BPG （ios）

BPG 是 H265 帧内压缩做图片压缩，webp 是利用 VP8 帧内压缩做图片压缩。图片压缩对于图片应用来说，除了能提升用户下载显示图片的速度，还能为企业节约带宽成本。

解决

P1

中

[Pngquant](https://pngquant.org/)

利用 PNG8 压缩 PNG 图片，颜色单一的图片，效果会非常明显。

解决

P0

低

[Wireshark](https://www.wireshark.org/)

实用的流量分析工具，包括 export http object, I/O graph 等等

发现 + 定位

P1

中

[Emmagee](https://github.com/kevinkong/Emmagee)

Android 的性能测试组件，里面涵盖很多性能数据获取的方法，可参考使用。

发现

P1

低

[HAR ](http://pcapperf.appspot.com/)+ [PageSpeed](http://stevesouders.com/flint/)

利用 tcpdump 在手机上获取的 PCAP, 利用 HAR 转换 PCAP, 然后给 pagespeed 组件分析。

定位

P1

低

弱网兼容性差（ios 通用）

ATC

Facebook 弱网络模拟工具。好处是模拟丢包，抖动的时候比较稳定，而且还有 HTTP API 可以调用, 方便和自动化配合。

发现

P0

中

[SPDY](https://www.chromium.org/spdy)/[QUIC](https://www.chromium.org/quic)

特别是 QUIC, 就是为了网络抖动而设计的。

解决

P2

中

[OKHTTP](https://github.com/square/okhttp)

推荐的 HTTP 组件。性能好，弱网兼容也不错。

解决

P1

低

结局篇

跟很多不小不大的互联网公司都交流过，测试的人力投入是非常有限的。当然更不可能有成建制的专项测试团队。所以正如前面提及的，找业务的痛点很重要，不求大而全。既然是痛点，就容易获得至上而下的支持，如果没有支持，就给信息给数据来说服，然后定底线定目标让事情持续有效。手 Q 的安装包就是个典型的案例，看到安装包一个版本就大 10M，其实没有感觉到任何的痛和担心，我们用数据说话，多少用户用 3G 下载，各个安装包大小的下载失败率是多少，最终让老大重视了起来，并且确立了安装包增量监控的工具和流程。另外很重要的是信任关系，而信任关系不可能一蹴而就，需要有产品痛点，沉淀正面和反面案例，老大重视，自身技术过硬，并且持续相互教育，之后的事情就会更加一帆风顺了。最后，总的来说，少点埋怨，调整心态，数据说话，坚持底线。

关于作者

黄闻欣，人称小 V，腾讯高级测试工程师，2009 年加入腾讯，一直致力于移动应用测试， 提升产品质量和研发效率， 目前加入手 Q 项目，负责双终端平台的专项测试工作，带领团队开发 BG 级稳定性测试产品 newmonkey, 性能监控库 perflib， 积累了丰富的 Android/iOS 应用测试和性能调优经验。个人是轻微偏执狂，锤子粉，两个娃的爸，一直认真执着保持初心的老鲜肉。感兴趣的读者可以通过微信号 @wenxinhuang 或公众号 @TencentTestForward 与他交流。