测试调试，这个阶段时是大家最不容易遗忘的，80%的精力都在这里，建设的工具也最多。这里的工具两类，度量类的和分析类的。之前我写过一篇《假如不是BAT,专项测试怎么做》，里面就提到过。这里不想多说，简单介绍几个特别的，思路可以借鉴和拓展的，
1. tPacketCapture手机无root抓包，这个应用的特点就是用了vpn的方式来配合抓包，大家仔细想像，当大家头痛为什么要root了才能抓包的时候，有木有想过这个思路呢？ 在这个思路底下，纯手机端的无root的弱网模拟，盖包，丢包，都不是梦呀。
2. MAT，LeakCanary，AllocationTracer，android-hprof-tools，dumpsys meminfo这些都是内存测试分析的工具。一大堆工具，能给我们什么思路呢？我们不妨从程序，代码，时间，规则这三个维度来看待我们的工具，android-hprof-tools优化抓取hrof速度的，与MAT快照分析配合使用，获取的信息是静态的代码信息，例如MAT获取是类名，对象数，引用关系等，这里没有时间的概念和信息，但是在代码之上，可以分析问题。而AllocationTracer就是在代码信息上，加上了时间的概念，可以称为动态的代码信息，这里分析的问题就必须跟时间是相关的，例如GC, 垃圾回收触发的时机对程序流畅度的影响。另外一个维度，隐匿了代码的信息，那就是程序的信息，这里top，meminfo，gc日志是代表，主要用来发现问题，因为相对轻量，持续时间可以更长。最后就是规则，在代码信息之上融合了规则的测试工具，会自动发现问题，最经典的就是leakcanary了。按照这个思路，大家不妨可以想想其他的专项工具，不要觉得没得想，最起码现在看来“代码＋时间＋规则” ＝ allocation tracer + 规则的工具，起码我至今还没有发现。
发布运营，发布就是研发流程外了，我们的质量保证不是应该在研发流程内彻底保证么？事实上，臣妾做不到呀。用户环境很复杂的，就以上次有个同学问我，国际网络测试要怎么办。我也只能厚着脸皮说，发布运营上做文章，做可以定位问题的数据上报。没错，研发流程内可以做一些相关质量保障，但投入产出比太低了，想想，难不成你要飞去美国做测试，当然，方便一点的就是买deviceanywhere的服务来做测试。如果能考虑灰度发布，那事情就简单多了。一方面，可以用applause提供的众测服务。另一方面，光“测”不够，因为在远端定位问题是充满悲剧的事情，必须要有远程定位问题的能力。定位信息有了，那征服“自定定位分析”，那为什么不动态运营一把呢？ 最经典的就是网络路由出口的问题，不同出口的网速到不同的地方，不同的运营商，天差地别，如果发现a出口不行，是不是自动动态划同一区域同一运营商可以试一下b出口呢？如果可以，是不是可以动态调整过来呢？这里有太多太多事情可以做了。上面说的必经是网络策略，那除了网络之外，对于功能，可以用ABTest, 如facebook的airlock, 监控工具可以用众多的APM(此处不列举）， 有bug可以用hotfix工具nuwa。
总结，容易遗忘的源码开发：效率最高；唯快不破的编译集成：联合代码信息；用力最多的测试调试：时间＋代码＋程序＋规则；发布运营：创造最接近用户的测试调试环境。
