测试效率低下？很多时间都在等程序开发功能，直到界面层展现出来数据后，我们才能介入测试，然后忙的焦头烂额，上线前心里还没底。亦或者发现一个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月的同比数据，那数据肯定又是错了。可能会有人问题，接口测试不是第四层做过了吗？怎么这里还要做？
... ...
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任
