关于接口测试的一点想法

        接口测试在大多数公司都没有定做必要环节，如果时间充足并且测试人员有这个想法就做下接口测试，或者后端开发完成前端迟迟不能提测，测试可以在间歇时间进行下接口测试，以期提前发现接口的问题。当然了，我以前也是在这两种情况中进行的接口测试。

        最近，由于测试leader有意培养所有测试人员的接口测试能力，也是工作没那么紧张，所以要求我们将正在运行的系统已上线的功能写成接口测试，以后优化上线前先进行已上线接口的测试，无影响才可以。而且团队中一直有一个被“大才小用”的测试开发，来带领大家一起做这项工作。

        一步一步，一个一个接口写下来，发现接口测试真的很有必要。不做接口测试，虽然能满足功能，但是潜在的危害很大。对于用户规模大，业务量大，对自己有要求的产品，接口测试不仅必要，甚至应该专门预留接口测试的时间。不然如果有用户想钻漏洞，有竞争对手想黑你，有黑客想攻击你，真的太简单了。

我想举几个实际的栗子：

1. 两个角色的用户分别可以对产品进行定价和接单，为方便描述，定义角色A可以定价，角色B可以接单。用A角色的用户登录后，能够看到定价的菜单，就能定价操作，用B角色的用户登录没有定价菜单，自然也就不能进行定价操作，只有接单菜单。这样在前端正常操作是没有问题的。但是如果用接口去测试，B角色的用户也可以直接通过定价的URL去定价，后端没有校验用户的角色权限。

2. 前端进行输入长度的校验，数据库存储的长度是100个字符，前端也限制100字符，但是后台没有处理，也就是通过接口发送超过100，后台没有限制，直接交给数据库，数据库就会报错。

3. 某个功能通过两个接口来实现，比如确认付款功能。先调用上传图片接口，上传图片成功后再调用付款接口。页面测试时，如果上传图片接口没有返回成功，不会继续调用付款接口。但是如果通过接口来调用，直接调用付款接口也是可以成功的，因为在付款接口里面没有对图片上传的结果进行校验。

4. 与1类似，也是在操作的时候没有验证用户是否有权限。比如说A没有审核权限，A登录系统看不到可以以审核的记录，但是直接用接口调用审核的话A是可以审核成功的。