基于业务的接口测试

基于分层测试的思想，单元测试，接口测试，UI测试已经被众人熟知。但是真正三层都在应用的公司却很少，即使是某些大厂，也并没有做到全覆盖，小公司就更难了。

首先我认为是思想的局限性导致的，大家都知道单元测试的收益最高，相对应的也应该在单元测试上花最多的时间，但是在产品开发的初期，还是有很多人想着怎么能够快速完成开发，让产品早日成型，赶快进入下一阶段的测试，这样貌似离上线时间就能快一点了。殊不知，UI测试阶段要花更多的力气来测这个阶段本不该做的事情，发现了问题又得从头找原因，时间成本，人力成本都被严重消耗。

第一说单元测试，因为各方面的客观原因，国内真正能实施单元测试的公司少之又少，大厂也是部分重点项目实施单元测试。当然，国外的公司单元测试是标配，即便是那种只有几个人的小公司，单元测试也是最核心的缓解。究其原因，还是人员能力有限，普通程序员不愿意做单元测试，产品人员不了解技术对编码阶段的质量无法跟进。很多团队从上到下都认为UI测试阶段才是功能测试的开始。所以就造成了上图所绘的现状。

其实我觉得基于现状，我们需要基本的单元测试，在开发初期尽早的反馈问题。着重在接口开发阶段进行功能测试。

现在很多中小型公司已经开始注重接口测试了，看到各大招聘平台的招聘信息里，接口测试占了很大一部分占比，说明对接口测试的需求十分旺盛。但是我的一些朋友进到一些接口测试刚起步的公司，却发现从上到下不知道怎么做接口测试。还停留在仅仅只验证接口返回数据的阶段，而并不知道怎么把接口测试和业务功能测试结合起来。感觉没有界面就不知道怎么做功能测试了。

我们知道后台和前台的交互，主要就是通过接口来实现，接口调通便以为着交互成功，接口返回数据准确，其实便意味着功能正确。那么我们需要做的就是把有业务关联的接口串联起来，组成一组一组的业务场景，数据在各组场景里走个完整的生命周期，其实就能够很自信地证明业务功能没有问题。这便是基于业务的接口测试。

例如：注册流程场景：首页->登录页->注册->个人中心

UI测试会按这个流程对产品进行操作，接口测试怎么测呢？

step1：首页的初始化接口，测试ok。

step2：登录页的注册接口，进行注册接口测试，注册时候的限制条件就用边界值，等价类的方法进行注册接口的测试用例编写，对各种情况的注册信息组合进行接口数据验证。

step3：注册成功的情况，到个人中心相关的数据表里核对数据是否匹配。

完成这3步，就完成了注册的功能验证。如果之后对代码进行了修改，测试也只需要按这个流程再执行一遍接口测试即可。对比UI测试阶段的执行效率，其实要高很多。而且能更快的给开发反馈问题，不用让开发等太久。最后再对UI进行检查即可完成所有测试。

在接口测试阶段，测试人员就要基于业务开始模拟各种功能场景，这对测试人员的抽象能力是一个很高的要求。所以大家需要通过不断的实战来训练自己，不断第总结经验教训，补充自己的用例库达到积累的目的。

最后，希望在做基于业务接口测试的伙伴能够积累自己的用例库；只在做接口测试的伙伴，开始有意识地训练自己抽象业务场景的能力；不会做接口测试的伙伴，开始学习接口测试。希望大家的测试职业生涯能够越走越顺，日子越过越好。

END.