关于对测试金字塔的理解收获共享

关于对测试金字塔的理解收获共享

前段时间去了51testing听了2天课，讲课老师是从微软外聘的，中间提到一个测试金字塔的问题，把我原来的一些疑惑、观点进行了很好的解释和印证，道理很简单，但不是每个测试人员都能理解透，故把收获共享一下。

金字塔的结构如下：

金字塔分为5层，最一层的是单元测试，是针对类库和程序集来进行测试；第二层为组件级的测试，我的理解是dll和接口级的测试；第三层为服务级的测试，像我们做GIS的，可以理解为地图服务，定位服务等；第四层为界面级的测试（如自动化UI测试）；最上面一层为手动测试，运行已经集成的系统，手工对系统的运行结果和预期结果比较。

 

 

 

摘自老师网站，地址：http://www./（基于敏捷开发的大型软件自动化测试架构）

 

观点一：测试越往下面测试的效率越高，测试质量保障程度越高，如下图示：

 

 

 

 

越往底层，测试的效率更高，程序的bug归根结底需要落到每个类上面，当保证了每个类的稳定后，越往上层就是集成的问题了。逻辑性bug在类库做组件内部解决。

举例说明：

       我曾经参与一个项目，某个系统每次一测试，都能发现大量的bug，对这个系统几乎快丧失信心，后来我把这个事情反馈给项目组的开发经理，这个开发经理把它的代码拿到后，直接看底层代码的逻辑，重新整理了各个类库之间的逻辑，加强单元测试的覆盖率。然后把系统给我的时候，发现原来很多bug自然没有了，质量很快就上来了，对系统有信心得多，有些地方我也偷了懒（不测也是提高测试效率的手段嘛）。

       越往底层测试，测试效率更高的还有一个方面最能体现，就是自动化测试。像单元测试，只要class中的方法参数不变，类库的名称不变（这些一般也是不会变的），这样自动化的测试脚本就不需要变化。而越往上层，自动化测试效果不会太好，尤其是系统界面经常变化的，造成自动化测试脚本的维护工作量非常大。据我所知，在界面层的自动化测试，除了office软件做得好的外，其他好的案例非常少。

 

观点二：测试越往下面测试的成本越低。

       Bug越早发现，损失就越小，成本也越低，这个应该是测试人员的共识了。同样道理，从这个金字塔也符合这个规则，也就是说这个金字塔是符合软件开发流程的，按照瀑布模型来说，单元测试往往是项目测试最前期的，到了界面测试了手工测试阶段，系统已经集成了。这个时候发现问题，如果这个系统很大的话，可能在问题定位上就得发不少时间，比在一个类中定位问题，花费的时间绝对多的多。

 

我自己也经历过一个事件，某住房补贴软件在刻了5000张光盘后，被测试人员发现了一个严重bug，这个直接影像到补贴金额的准确性，导致5000张光盘重新刻录。好在光盘还没有发出去，否则后面的麻烦事估计公司得专门成立一个部门来解决了。

 

观点三：测试越往下面，职业发展前景越好，同时也回答了测试人员是否需要开发功底的问题:

 

       越往金字塔底层，测试的技术含量要求更高，测试人员的核心竞争力更大，薪酬当然要高一些，如果从技术方向来说，可以做高级测试工程师、测试架构师都有可能。老师给我们讲了一个微软测试人员人数变化的例子，在微软早期，也有不少手工测试的人员，这些人员也是不需要编写代码的，由于微软从事的产品为主的公司，这些手工测试人员根本无法满足测试工作要求，逐步推行自动化测试，随着自动化测试的深入，到了2003年左右，不懂开发的测试员已经远远少于有开发功底了，到了2008年左右，不懂开发的测试员已经消失了。

      

       随着自动化趋势的加强，希望网上对于测试人员是否需要懂开发的争论希望少一些吧，也希望认为因为测试比开发简单的才加入测试队伍的，如果你到现在还一直这么认为的话，我奉劝你尽早放弃测试工作。

需要补充说明的是，手工测试并不是完全丢弃的，因为测试一定要站在用户的角度，站在业务层的角度。越往金字塔的上层，在测试时越能体会到用户感受，特别是项目型公司，我这里强调的只是从测试比重分布不同而已（要加重底层的测试比例）。