基于我自己的一些理解和观察，我试图把测试工作的层次分成三个阶段，越到后面涵盖的范围越广。这里讨论的一些做法可能更偏向于互联网方面的测试，特别是第三个阶段。
首先我想先从一个例子开始，一个现实生活中的例子。
对于一个城市，假设我们的工作目标是提升环境的质量，减少垃圾。那么我们可以做什么？
首先，我们可以请很多环卫工人，出去打扫各个街道，这个马上就有了效果，环境变得更干净了。但是还不够好的地方是明天还是有很多东西需要打扫，治标不治本，只要一停下来立马回到之前的状况。
接下来，我们往前面想一想，为什么有那么多垃圾呢？其中一个方面是很多人乱扔垃圾。所以更进步一点的方案是，对于乱扔垃圾的人有些约束或者惩罚，比如抓到了曝光或者罚钱，这样扔垃圾的人会变少。
再然后，我们发现即使做到了上面，还是有不少垃圾，而且上面强制的方案也带来不少的反感。我们需要更深层次的思考，为什么会有那么多垃圾？是因为垃圾桶太少？设计得不合理？如果是这样，就需要从其他公共设施方面做一些改进了。
对于我们的测试工作，也是有类似的思路，只不过细节上要考虑更多。
第一个阶段：发现和解决bug的阶段
这个阶段的思路基本上尽可能发现更多的bug，见一个灭一个，来两个灭一双。
发现bug，解决后验证bug，没有任何根源性的推动，或者推动的效果不好。
这个阶段，测试工作主要集中在发现bug，要做好这个，需要多个方面的努力，比如下面这些：
- 更高效的发现bug，考验测试设计的能力。
这方面有非常多的方法和技巧，以及经验，这里不细说。
- 发现bug之后如何清晰的描述，定级，以及跟进和验证。
这个看似简单，但是你会发现很多测试工作做了几年的人这样的基本功还是不够扎实。也可能没有受到过很好的训练或者一直没有人指导。
- 对业务和架构的理解能力。
没有这方面的能力，很难发现一些深层次的bug。而这样的能力对于快速学习和一些技术基础也有不低的要求。
- 发现bug之后如果举一反三的尽早发现更多类似的bug。
大家看到的很多经典的测试书籍讲的基本都是这个阶段做的事情，比如Software Testing，How We Test Software at Microsoft，以及探索性测试相关的书籍，都是专注在如何更高效的发现缺陷。
上面这些东西都是一个业务测试人员的基本功。看似简单，但是做好并不是一件容易的事情。也许这些事情一点都不cool，不sexy，甚至去做职级评审的时候不占优势，但是对于系统质量的提升，是切切实实带来很大帮助的，其工作的价值应该得到认可。但是如果一直停留在这个阶段，就陷入到上面例子中说的扫马路的阶段，因为如果没有其他方面的改变，每次都有那么多的bug。
不过很多时候，我们的测试停留在这个阶段也是因为现状，考虑下这样的情况：
- 开发基本不自测，甚至没有自测的环境，特别是涉及多个系统的对接。
- 提测后很多基本的功能都不能正常使用
- 项目管理比较混乱，但是最终的发布日期又被老大们定死，所以测试时间常常被压缩
而且，而且没有对于开发人员的质量方面的考核，那么很长一段时间，我们的测试将处于这个初级阶段。
我相信目前还有不少的团队是处于这样疲于应对的情况下，不只是小公司，可能一些大公司的部分项目也是如此。随着整个研发体系的发展和深入，我们应该有更高的追求。
第二个阶段：质量的管理
在第一个阶段中，可能有一些人会停下来想：我们一直这样下去也不是个办法？有没有更好的做法呢?
最直接会想到的就是，怎么让别人少丢垃圾，让本身的bug就更少一些。如果我们做的工作只是发现bug解决bug，那么就是一个消耗战。不能形成一个良性的循环，就不能持续的优化，工作的长期累积价值就体现不出来。
这个阶段核心的思路是对缺陷做分析和考核，并做研发流程中主要问题的梳理和改善。
常常做的事情可以从下面几个方面来看：
1. 做质量数据的统计和分析
收集的数据很多，常见的有：
- 外网的bug情况，包括事故，及影响的程度
- 测试阶段的bug数量，分布（按系统，团队，开发个人），严重程度，bug的类别等维度
- bug的横向跨团队和系统的对比，纵向的和历史情况对比
- 版本发布的情况，代码变更行数的情况
从这些数据的收集中就能发现很多问题，比如问题集中在哪里，哪些模块，哪些人，哪些类别等等，以及有没有改善。
2. 问题的追溯和对于开发的考核
这个方面也许有一些争议，但是我还是觉得这个是一个很重要的方法。光靠观念和自觉是不够的，必需要有一定的反馈机制，就好比交规一定是配合着扣分和罚款等手段，否则记录闯红灯有什么意义呢？而且现实的来说，这些方法起到约束的作用，也是一种心理暗示，要做自己做的东西负责，也便于养成好的习惯。
