软件测试工作的三个阶段(4)

　　发布处在整个研发流程非常关键的节点，在这个点可以做很多的控制，也能发现很多的问题，对于测试团队来说，从这里可以发现很多的问题，做很多的提升，对自己和相关的合作团队。

　　5. 外网的监控

　　发现发布后的问题，持续运营过程中的问题，推动优化。

　　通常监控可以分几个层面，粗浅的可以分成几类：

　　- 运维层面的监控，比如机器，链路，资源使用，主要组件是否正常等。

　　- 业务指标的监控，比如来自点击率，BI系统等。

　　- 集成在产品里面的监控代码，我们称之为模块调用监控。这个是全量的，有次数，成功率，响应时间等角度。

　　- 测试层面的自动化监控，关于在接口和功能层面。这个是采样的，但是从用户的角度来监控。

　　以上这些监控都有对应的告警机制，可以第一时间发现问题，避免造成更大的损失。为了实现上面的监控需要做大量的工作，但是这些对于整个外网运营的质量非常的重要。

　　6. 外网事故和问题的收集，跟进和反向推动

　　和前面的思路一样，如果只是发现问题解决问题还是稍显被动，那么对于外网事故和问题的分析，还是有很多推动性的帮助。

　　7. 用户的问题反馈和满意度

　　进一步的质量不只是系统本身的质量，而是从用户角度看到的质量，有时候这个可能稍微超出一些系统层面的问题，但是因为最终的质量还是用户说了算，所以我们应该扩展下思路。收集这样的问题的渠道有很多

　　- 外网问题反馈，比如来自客服系统的，用户直接的反馈，现在很多app上都有反馈的功能。

　　- 论坛信息的统计收集。我了解的另一个测试团队，他们还专门开发了一个自动收集外部反馈，以及过滤分析的系统来帮助他们及时的了解外包的问题反馈。

　　8. 运营层面的质量

　　更进一步，关注运营方面的质量，跳出传统意义的质量的范畴，关注我们的业务指标，不只是做一个高质量的产品，而是做一个业务上成功的产品。

　　比如下面这样的例子：

　　- 商品详情页的图片的质量

　　- 活动页面和详情页面价格不一致的情况

　　- 运营配置的错误导致的问题，哪些是可以监控发现，哪些是可以推动运营平台的规则检查?

　　每次我们的思路跳出一些框框，都会有不同的领域。有点点哲学上的意味，很多领域做到后面，其实会超出那个领域本身的范畴。就好比高性能的汽车，到后面就不得不研究空气动力学这个原本是和航空有关的东西。但是，这是否超出了本意，如果去看待，又是另一个问题。

　　其实这样的三个阶段也是一个粗略的划分，并不一定要逐步的来发展，其实都是一些具体的做法和实践。以我目前经历过的实践只想到这样的层次，应该还有更高级的阶段。

　　我们越到后面我们发现进一步的努力带来的提升幅度其实不大。但是很多事情也是一样，从85分到90分付出的努力可能比50到80分的努力还要大。另一个更有趣的是汽车的极速和马力的关系，家用车100马力开到180km/h是能做到的，但是超过时速300，每提升一点需要增加的马力要大得多，到400以上，车时速每再增加一公里，功率需要提升八马力。这篇文章读起来非常有意思，http://blog.sina.com.cn/s/blog_4d0109a301000ajz.html

　　写到这里，我们可以跳到整个公司或者业务的层面，来思考一些对于测试更深层次的问题:

　　测试团队存在的价值和意义是什么?

　　只有对业务有明确的价值，业务测试，或者说整个测试团队才有存在的意义。只要业务OK，砍掉测试团队也不是不可能。我们必须时不时的跳出我们自己的思维的圈子，站在整个事业部老大的角度来思考下测试的价值和意义。

原文转自：http://blog.csdn.net/superqa/article/details/21485737