其实这个话题对于身在BAT的我来说，是个难题。因为BAT对测试本身的投入力度，在行业内是走在前面的。一直在这个环境成长，可能会不理解其他小团队的痛。但是我意识到，必须写一篇文章，一方面是因为最近确实接触了一些腾讯系公司，了解了他们的测试现状，我觉得需要有所总结； 另一方面是希望自己透过这个文章有更进一步的思考，最终能给出一些可以真正帮助到测试行业内其他团队的意见。
心理篇
我在QCon北京上的演讲《手Q专项测试最佳实践》中曾经提过，专项测试有资源类性能、交互类性能、稳定性、兼容性和安全性等等。但仔细想想，对于一个小团队，一个创业或创业初成的团队需要管那么多吗？不用，只要心中有概念， 并有对应保底措施即可。对于小团队来说，更重要的应该是打痛点，因为痛点是产品发展的最大障碍，具备极高的性价比。但是什么是痛点呢？表面上很多产品都知道自己的痛点，其实并非如此。在不了解用户反馈的情况下，说自己明白用户的痛点，并且创造产品需求的比比皆是。所以对于专项测试而言，第一步无疑是找痛点。
第一步是建设反馈系统，找痛点。这种反馈包括各种用户反馈的收集分析，各种专项数据的前段和后端的上报分析。有一些如听云、OneAPM，Bugly其实已经有一些这种监控上报的能力，只可惜在用户反馈收集和分析上，暂时没见到对应的系统。所以在应用现有系统的基础上，可能还需要自建。那么，假如有了这些系统，帮助我们知道有多少用户遇到卡死， 实际Crash率是多少，多少用户说耗费流量，实际终端耗费流量上报结果是多少。这时，痛点自然就一目了然，未来能达成的目标也清晰可见，老板也许会更加清楚地了解问题的严重性，从而下定决心改善。
第二步是找底线和目标。我们有了反馈系统，知道了用户的实际情况，这时我们就需要根据数据让团队自上而下地明确底线和目标，从而提升后续团队合作的效率。目标可以是，Crash率是多少不让发布，Crash率是多少可以不FIX, 切换界面底线是多少，百分之多少的用户的流畅度是多少，用户反馈的卡顿问题从TOP10问题剔除等等。
第三步是解决问题。有痛点有解决痛点的目标，我们就要行动，为了达成目标，解决问题。我们以及我们的平台需要具备如下三个能力：
第四步是回到反馈系统，展示效果。开发，测试忙活了许久，达成了效果，却没有展示，那就是错失了开发与测试形成信任关系闭环的最佳时机。当然也缺失了进一步改进，做就精品的机会。就如我们的上传图片，一开始的目标仅仅是提高成功率，然后就是让带宽好的传输速度更快，再后就是让网络差的也能在保证成功的基础上再快点，再想办法搭救更多的在演唱会时发送不出消息和图片的用户，一路上都是不断地看数据上报，分析，解决问题，展示效果，再分析，再解决，再展示效果，形成闭环。
工具篇
一般来说，用户最痛苦的专项问题，通常是最表面和直观的问题，包括：
闪退：包括CRASH，系统强杀，ANR，直接影响用户的使用。
卡顿：包括丢帧，动画帧率低，相应用户操作速度慢，甚至是卡死，但却没有触发ANR或者watchdog timeout。这些给用户的感觉就是用得不爽，尤其是有对比的时候。
流量大/速度慢：移动应用必然面对流量问题，我们至此为止都会看到月末时候的流量效应，就知道这个的重要性。况且对于小公司来说，更痛的可能还是带宽，CDN的费用问题。
弱网络兼容差：用户面向的网络情况其实是时好时坏的，但是用户期待业务能执行成功，哪怕多耗费一点时间。
待机时间短/手机发烫：自IPHONE开始，每个手机都需要“吊盐水”（使用移动电源）。如果他发现你在耗电排行榜TOP1, 却一直在后台毫无建树，相信用户会好不犹豫地删掉。
业务专项问题：不同的产品有不同的业务专项问题，单独说出来是因为前面4个是通用的，请大家不要限制自己的思维。根据业务特质还有一些专项的指标会产生，例如地图应用定位的准确性，广告能力推送的准确性，音乐软件播放的音质，图片应用图片的质量。
下面针对这些问题，我们来看下我们有什么工具可以帮助到我们。没有像BAT这样的资源投入，但是问题还要解决。下面小V给大家推荐一些跟我们内部的建设思路近似的外部开源工具来帮助大家解决问题。（PS: 我只推荐我认为落地成本低产出最高的工具给大家，所以有些工具我不是不知道，而是投入的问题。并且下面我不再说专项指标，我会说是痛点，因为专项指标肯定不只有这些。下面的内容我尽量客观，但是不排除有一些主观判断，毕竟我没有每个都深入使用。）
