3. 测试能力的提升
　　测试阶段有很多的事情可以去做，觉得主要的还是两个方面
　　- 自动化。 越来越觉得这个是绕不开的话题，要想尽办法去做，做得更高效更全面。前面有篇blog也提到了一些轻量级的做法，业务测试的团队可以参考  http://blog.csdn.net/superqa/article/details/20644285
　　- 辅助手段，比如代码覆盖率，特别是差异的覆盖率。这个大家都比较容易理解不展开了。
　　- 拓展测试的类型
　　这个方面说起来有些泛，需要结合团队和业务的情况，比如安全测试，性能测试，兼容性测试等，去发现一些对于产品来说很重要的风险。
　　这方面有两个前提，一是我们的基本功能质量到了一个阶段，可以让大家腾出手去拓展测试的面，另一方面我们测试人员的能力要跟得上。
　　4. 发布环节的质量把控
　　这个方面和传统的测试不太一样，而且了解到不同的组织做法不同，执行发布的人员可能不同，有开发，运维，专职的版本管理或者测试来做。
　　在我们的实践中，发布后来都逐步收到测试这边，回头来看觉得还是有不少有帮助的地方。当然也不的必须测试来做。
　　- DO分离，避免了随意的发布，特别是在开发手上的时候。所有的bugfix都经过测试发布，可以更准确的度量质量（除非这个问题可以不修复，否则肯定要过发布环节）
　　- 知道近发了什么，可能的影响是什么，需要线上关注什么。
　　- 灰度。 互联网产品常用的一个控制风险和节奏的手段。
　　- 扩容的快速自动化检查，这方面也依赖于自动化的建设。
　　- 发布过程支持灰度的控制，备份和快速的回滚。对发布系统有一定的要求，而且有可追溯性。

　　发布处在整个研发流程非常关键的节点，在这个点可以做很多的控制，也能发现很多的问题，对于测试团队来说，从这里可以发现很多的问题，做很多的提升，对自己和相关的合作团队。
　　5. 外网的监控
　　发现发布后的问题，持续运营过程中的问题，推动优化。
　　通常监控可以分几个层面，粗浅的可以分成几类：
　　- 运维层面的监控，比如机器，链路，资源使用，主要组件是否正常等。
　　- 业务指标的监控，比如来自点击率，BI系统等。
　　- 集成在产品里面的监控代码，我们称之为模块调用监控。这个是全量的，有次数，成功率，响应时间等角度。
　　- 测试层面的自动化监控，关于在接口和功能层面。这个是采样的，但是从用户的角度来监控。

　　以上这些监控都有对应的告警机制，可以第一时间发现问题，避免造成更大的损失。为了实现上面的监控需要做大量的工作，但是这些对于整个外网运营的质量非常的重要。
　　6. 外网事故和问题的收集，跟进和反向推动
　　和前面的思路一样，如果只是发现问题解决问题还是稍显被动，那么对于外网事故和问题的分析，还是有很多推动性的帮助。
　　7. 用户的问题反馈和满意度
　　进一步的质量不只是系统本身的质量，而是从用户角度看到的质量，有时候这个可能稍微超出一些系统层面的问题，但是因为终的质量还是用户说了算，所以我们应该扩展下思路。收集这样的问题的渠道有很多
　　- 外网问题反馈，比如来自客服系统的，用户直接的反馈，现在很多app上都有反馈的功能。
　　- 论坛信息的统计收集。我了解的另一个测试团队，他们还专门开发了一个自动收集外部反馈，以及过滤分析的系统来帮助他们及时的了解外包的问题反馈。