转自：51Testing
测试效率低下？很多时间都在等程序开发功能，直到界面层展现出来数据后，我们才能介入测试，然后忙的焦头烂额，上线前心里还没底。亦或者发现一个Bug，发给程序猿A查，程序猿A说，可能是程序猿B的问题，你让程序猿B查查。程序猿B说，我这正忙着呢，你让A先查查，然后这个Bug就丢在那里好久，都没有人解决。你除了觉得很苦恼，可能也没有其它办法。如果你遇到这样的问题，那就赶快一起来了解下分层测试吧。
之前有在做企业用户数据统计分析的项目。其中有一个功能，计算新增注册用户的同比百分率。那就拿这个相对简单的功能做实例，讲述分层测试的过程。不过先别着急，在做分层之前，有一件事情是必须要做，那就是必须要了解数据源从哪里来，经过哪些关卡，才最终呈现的页面上来，才能做分层测试。
第一层测试：注册帐号后消息是否进入到rabbitmq队列？
如果说消息发送失败，或者在连续发送大量注册信息后队列卡住，那么后面的我们也没有必要去测试了，数据肯定就是错的了。通过下图可以看到消息是否进入队列？是否出现unacked？消费速度是否快？
当确保这关卡没有问题的时候，我们即可以进入下一关卡的测试。
第二层测试：注册帐号的信息是否按照要求记录到数据库，且无数据丢失？
打开数据库表，查看下数据字段是否齐全，值是否正确？比如说注册帐号要求写入数据库字段有，用户名，注册时间，注册时候需要的手机号码。特别是时间很容易出现bug，如果要求记录到秒，但是却记录到分钟或者小时，都有可能造成后续数据上的统计错误。
再核对下第一层测试中发送的数据量和写入数据库的数据量是否对等，如果有多了，有可能是数据重复发了，少了可能是数据写入有问题。
当确保这关卡没有问题的时候，我们即可以及进入下一关卡的测试。
第三层测试：聚合数据程序是否正确？
考虑到统计性能，往往对原始数据做一次聚合，减少数据量，提升统计性能。比如说要求是将注册的账号数量按月聚合存放到数据库表中。那么我们就需要去验证聚合后的数据库中的数据是否正确。
首先将原始数据库表中的数据通过查询语句把某个月的数据count出来，再到聚合后的数据库表中去核对该月的数据和count出来的数据是否一致?假如这块测试下来也没有问题，那么我们就妥妥的进入下一层。
第四层测试：通过接口调用，验证服务器返回的数据是否正确？
虽然经过上一层的数据库测试后，存放的数据是对了，但是服务器返回的数据可不一定正确。因为服务器可能会拿数据库的数据再次做运算后返回给前端。
比如说同比数据，就需要再次做运算，服务器把当前月份的注册用户数据（A）和去年同月份注册用户数据（B）取出来，然后通过(A-B)/B*100%的运算得到同比数据后返回给前端。可能有的同学会觉得这个运算那么简单，是否可以跳过？有意思的是，程序猿就在做这个算法的地方计算成了(B-A)/B*100%,导致了一个bug。此时你不用再去确认，是不是发送数据出问题了，还是说数据存放有问题，还是说聚合有问题，直接召唤写这段代码的程序大哥，嘿，就是你那里出问题了，并告知如何修改。是不是很有成就感?至于接口调用测试，你可以借助接口测试工具，如SoapUI，Jmeter，或者python都可以做。
第五层测试：前端页面展示是否正确？
终于测试到最后一层了，经过前面的层层把关，到这里可以说bug不会太多了，除非前端代码太烂。那么到这层我们测试些什么呢？比如说前端发送的请求是否正确，假使我要查询2月同比数据，愣是发成了请求1月的同比数据，那数据肯定又是错了。可能会有人问题，接口测试不是第四层做过了吗？怎么这里还要做？
很简单，第四层我是通过接口测试工具自己写的请求体，参数传的正确，服务器才能返回正确，但是前端程序猿在写调接口参数时，我可不保证他能把请求传正确，所以这是个很重要的验证点。通过抓包工具fiddler，httpdebugger都可以轻松找出错误。
其次就是数据在前面的展现是否正确，这块按着方案来测试基本也就没有什么太大问题了。往往数据显示保留位数，数据过长显示不全或者换行等地方会出现问题。
现在有没有体会到分层的好处了？整个测试过程思路始终是清晰的，每一个环节都能层层把关。我不需要等前端做好了，才能测试，任何一个环节做好了，我都能测试。等等，我估计有人又会有疑惑了，这个五层不是一环扣一环的吗？是不是一定要按这种顺序来测试？假设程序猿提前将第三层，聚合数据这块做完了，其他的第一层和第二层都没有完成，我能不能测试？
答案是肯定的，虽然我们缺少第二层中的用户注册数据，但是可以通过写脚本，将注册数据插入到数据库，再跑一下聚合程序，就可以测试了。
掌握分层测试的方法，能缩短整个项目的周期，且质量有保障。程序开发过程，测试也一并在测试，时间并行后，周期就缩短。另外刚写好的热乎代码，马上测试，发现的bug也能更容易找到并能立马改掉，程序猿效率也提升了。改变测试任务前松后紧的状态，你值得拥有。