对自动化测试的几点思考（二）

在测试金字塔的模型中（很多人应该熟悉该模型），最上面一层是UI层，中间一层是API层，底层是unit层，也就是说越往下在测试中占的比例会越大，程序越稳定和健壮，越往上站的比例会越小。那么在自动化测试技术选型中，应该是全部选择还是有所取舍。UI层在互联网产品中越来越跟不上节奏，这并不是UI层自动化测试的错误，而是市场在不断的变化，产品得跟上市场的变化，所以就导致了UI层变化很快，在页面对象设计模式上是可以很好的维护，UI层在产品快速变化，快速迭代，执行时间上效率问题导致无法满足在互联网产品中的应用，但是不可否认的是UI层的自动化测试思想包含了很多有价值的体系和方法论。也可以应用在互联网产品测试中，比如核心流程使用UI层实现，其它的不需要等等，这在实际的应用中具体看产品，公司实际情况。

如果一个产品不做UI层的自动化测试，那么再不做单元测试(一个产品很多时候是多种语言综合开发，做单元测试对测试而言挑战很大)，就只剩余接口测试了。接口测试怎么来通过技术的手段来保障产品的质量，以及执行的速度，在接口测试的层面，执行速度是可以接收的，特别是在jmeter这些测试工具中，即使上千的接口用例执行速度也就五到六分钟出结果，再回到刚才讲的通过技术手段来保障产品的质量问题。抛开技术的角度，一个产品在市场的表现无非就是它解决了用户的痛点，有良好的用户体验，业务执行起来没什么问题。痛点这属于产品思维，用户体验这个话题过于庞大，还是单纯的来看业务部分，对一个测试团队来说，保障产品的业务逻辑功能是最基本的功能，也是最核心的，这属于产品在市场的最底层的需求。如果一个产品在业务逻辑和功能存在问题，即使解决了痛点，市场也会放弃该产品。那么也就是说对产品做接口自动化测试，首先要解决业务的问题，接口测试至少测三个层面，具体是：

1、接口的端到端，一个HTTP的请求流程是客户端发送请求到服务端，服务端响应回复给客户端，端到端就是测试这个过程服务端返回的HTTP状态码是否是200；

2、接口的校验 比如添加用户的一个接口，当username参数为空，或者username参数超过边界值，客户端发送数据到服务端，服务端有没有做处理，这个过程在接口测试中需要增加接口的错误校验来验证后台程序的处理。

3、通过接口测试手段解决业务的问题，比如有这样的一个业务，添加用户，查询用户，编辑用户，删除用户，那么接口用例的顺序是先有添加,然后是查询，再有编辑，最后是删除，这个顺序是不能错乱的，试想如果删除接口在添加接口之前执行了 删除用户的时候首先需要用户的ID，而此时用户没有创建，传的用户ID不存在，也会导致删除的接口执行失败，可能服务端会返回请求参数错误，或者其他的错误等等。那么这个过程正确的是先执行添加用户的接口，获取用户的ID，接着查询用户，断言用户的username是否和添加时候的用户username一致，再接着编辑用户，编辑用户的时候传用户的ID，最后是执行删除接口，删除接口也需要传用户的ID参数。

通过如上几点，可以看到在一个产品测试中，通过接口测试的技术来保障产品质量有很多的优点，一方面执行速度快，另外一方面即使产品改变，但是在接口层面修改的可能性相对来说很小，更多的是样式的调整，接口用例维护成本低，另外一个有点是接口测试用例解决了业务的问题，也就是说产品上线后，执行接口用例几分钟可以得出产品质量是否OK的结论。

2011 年以及接下来的几年，移动互联网进入到了一个顶峰期，开发模式的改变，目前大多数开发模式是前后端（前端VUE）的分离开发模式，也就意味着作为测试必须得懂接口测试，了解发送一个请求到后台到底发生了什么，出错的情况下判断究竟是前台的问题还是后台的问题，以及如果是后台的问题，通过什么样的方式把返回的json格式的字符串给开发。某些时候，特别是涉及接口的错误，通过描述往往是描述不清楚的，但是给开发相应的请求参数，URL，响应内容开发很快就会明白是什么原因导致程序出错。本人也下来在周末的时间分享postman,jmeter,requests,json,数据驱动，持续集成，接口测试框架知识的分享，如想参加的同学可加我QQ：2839168630。