漫谈接口测试

在前面的很多的文章对中接口测试有很多的介绍，包含了常用的接口测试工具postman，以及测试工具Jmeter(目前在持续介绍中)和使用Python代码来做产品的接口自动化测试。一个问题，一起思考，我们为什么要做接口测试？我们为什么不做UI的自动化测试了？曾经有那么的一段时间，我是很倡导UI级的自动化测试的，因为它的出现，解决了手工测试的事情，而且也可以对浏览器进行兼容性的测试，当然还有很多的优点，也许最大的优点就是我下班的时候执行我的UI自动化测试，早上来我可以看到测试报告，然后感觉有那么一丝的成就感，但是渐渐的我不那么的喜欢了。首先就是在晚上上线的时候，它对我没有帮助，或者说帮助不大，0点上线，大家都等待着冒烟测试的结果，如果执行UI自动化测试，时间是1-2小时，也许更长，这么长的时间，我有耐心可以等下去，但是其他人没有，另外一个深层次的问题是产品每个迭代UI都不不断的调整，即使框架是多么的完美，但是谁受的了每次的调整，这个能够抱怨产品经理吗？市场在变化，客户在变化，产品必须满足客户的要求并且随着市场的变化而进行调整，这是毋庸置疑的，这种调整不几个版本能够调整出来的，找到用户的痛点并且总结出高频的用户场景不是一件容易的事，应用市场有那么多的产品，失败的无人搭理的远远大于成功的产品数，所以某些程度上，产品的调整更多是战略上的思考，而这些作为测试来说，只能配合，那么UI的不断调整不断维护，给人更多的是一种力不从心，或者是质疑，自动化真的就那么的重要并且真的解放了测试的人力问题吗？不得不承认，这个问题我听到过很多次，也有人问过我很多次，每一次改进，都必然经历质疑和怀疑，这点只能使用未《未来简史》里面的一段话来作为回答：人们只所以不愿意改变，是因为害怕未知。但是历史唯一不变的事实，就是一切都会改变。如果不改变，一切就又回到了最初的原点，进行手工测试，这些很多人不愿意接受而又迷茫的地方，一方面我们相信技术可以促进生产力的进步，在一定程度上可以解放人力的劳动，另外一方面就像上面描述的陷入到了UI自动化测试的死局。任何一个技术，都有它存在的比必然价值，但是选择适合自己的测试技术是最佳的一种选择。

我们必不可停止探索，而一切探索的尽头，就是重回原点，并对起点有首次般的了解。回到程序的本质，回到测试的最初点，目前的开发模式基本都是前后端的开发模式，在测试金字塔的模型中，最底层是单元测试层，中间层是接口层，最上面是UI层，依据它的理论，越往下投入的越多，它的价值越大，比如单元测试投入的比例很多，到集成测试的阶段，基本已经存在很少的问题，最多可能是中间层或者是场景化的问题，而程序内部由于经过了大量的单元测试存在问题很少，但是做单元测试的公司又有多少？能够自测自己代码的开发又有多少了。大多数时候，转测给测试的本版，属于调试阶段，各种想吐槽又不知道如何吐槽，现实也许就是如此，对于测试而言做单元测试部分，可能涉及到技术层次不到位等等因素，这一层的测试只能期待，而不能强求。

那么剩余的就是接口层和UI层，我的理念是弱化UI层，强化接口层。通过接口测试的形式来做产品的业务，接口执行的速度是非常快的，即使上千的接口用例，执行也就十几分钟出结果了，而不需要等太久。可能会有人担心接口执行通过，能够证明产品的业务功能是好的吗? 只要接口用例覆盖了产品的业务逻辑和测试点，那么可以说是正确的，当然也有接口测试所不能测试到的地方，比如前端的交互，这些和后台没任何的交互，接口测试是无法到位的地方，可以人为的去检查下。在接口测试方式来做产品业务的时候，有两点非常重要，第一点是测试场景，或者说是测试点要覆盖到位，第二点是断言要合理，如果二者有一点存在问题，那么测试执行的结果是要打折扣的，或者说这个测试结果是不可信的，不够权威。有下一节会再次的写下接口测试的几个方面，本计划今天晚上写的，已经11点了，准备休息。