8年测试经验之谈 —— 接口测试用例设计思路(通俗易懂)

一、接口测试的流程：

需求分析(需求文档、开发提供接口文档)→测试设计→测试用例评审→测试执行→验收→预发布→上线

二、基本功能流程测试：

冒烟测试(主业务的正向流程)、正常流程覆盖测试(正常分支的业务流程进行覆盖→分支覆盖、路径覆盖、业务场景覆盖)。

三、给予输入域的测试：

边界值测试、特殊字符校验、参数类型校验、必选参数校验、组合参数校验、有效性校验、默认值校验、排重逻辑

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036

四、接口幂等性：

重复提交；保证系统的幂等性。

幂等性的改造：可以增加一个唯一的参数。

幂等性场景：网络重发、系统重试都会造成重复的这种一个请求，这个时候，就需要保证接口的幂等性，尤其是对于在这种涉及到资金的这种系统当中，比如说：银行、电商系统，幂等呢，是非常重要的一个地位。比如说，我们一个接口，它会从一个账户当中去扣除传入这个数额的一个钱数，如果说，扣除成功，我们就返回true，那我们的余额就减少传入的这个钱数，如果说，扣除失败，我们就返回false，我们的余额不变。那么会有这样一种情况，就是我们这个请求已经发送出了，我们服务端也正确处理了，但是呢，我们服务端的返回结果由于我们网络的一些原因丢掉了，导致我们客户端没有得到这个处理的结果，那如果是在这种交互设计或者是说前端展示上处理的不太好的话，提示不太好的话，那用户呢，可能就认为他这次操作失败了，然后呢，他就会刷新页面或者是说重复去提交请求，这个时候，就会导致我们的就扣被调用很多次。那这个时候账户可能也会被多扣钱。这个后果就很严重了，所以，为了解决这样的问题，我们就需要对接口进行幂等性的改造，我们可以去给他增加一个唯一的参数，我们客户端的同一个业务请求就只有这一个参数，那服务端呢，就可以在收到请求之后去检查一下是不是已经存在了这个参数，并且已经执行成功了，如果说，执行成功的话，就不会再处理第二次请求的一个调用了，这样的话，就避免了这种重复扣款的问题。最重要的是，我们测试的时候怎么去做呢？我们就需要多次的去发送用同一个参数的请求，重复提交，看看我们服务端那边的响应到底是不是正常，这是我们要保证接口的幂等性。

五、故障注入：Redis故障降级测试、服务器故障转移测试。

比如说，我们在登录的时候可能就需要从我们的这个服务端去获取这个登录的token，那这个token其实就可以把它存到我们的这个Radis当中，那后面呢，我们的客户端如果说发请求想要获取token的时候，就可以先到redis当中去查询有没有已经缓存好的token，那如果有的话，就直接从redis中去取就可以了，如果redis没有，再继续的从我们的这个数据库当中再去取对应的一个token值，当然了，取出来之后，需要先回写到我们的redis当中，那么等到你下一次再去发这种获取token请求的时候，就可以直接的从redis当中去读取了，对吧，这样的话，既可以提高访问的速度和效率，也降低了我们数据库的一个压力，所以说呢，redis用的还是比较普遍的，那我们redis的故障注入要怎么做呢，这个时候呢，我们可能就需要开发去配合我们了，我们可以让开发配合我们先去清空我们redis的数据，然后呢，我们发出一个获取token的一个请求，看看能不能够击穿redis，从我们数据库中获取正常的数据，而且呢，还要看看能不能正确的回写到redis当中，然后呢，我们还需要让开发再配合我们去启动我们的redis,恢复我们的数据，然后呢，看看能不能从redis当中获取正确的这些数据，那再有呢，我们还可能需要开发配合我们制造一些redis崩溃的场景，看看能不能再这个请求发出去的时候，能够降级到我们的这个数据库当中去获取到正确的数据，这就是我们redis故障降级测试，那除了redis之外，我们还可以去做一些服务故障转移的测试，那比如说我们数据库的一些故障，对吧，我们可以让开发配合我们制造一些数据丢失的场景，然后，启动我们数据回复的策略，看看在规定的时间里头，我们的数据能不能恢复，再有呢我们需要让开发配合我们制造一些数据库崩溃的场景，看看我们的数据库这种多活策略能不能启动，功能受不受影响，那除此之外呢，我们还可以去做一些接口转移的一些测试，比如说呢，我们让开发配合我们做一些接口服务的重启，看看我们的这个请求有没有异常，然后呢，再去制造一些集群崩溃的场景看看呢我们的这个接口能不能返回一些对应的错误，我们内部的服务有没有一些重试的一些机制，对吧，像这些呢，都是属于故障的注入。

六、线程安全测试：并发测试、分布式测试、数据库读写安全测试

分布式，更多的是一个概念，它是为了解决我们单个的物理服务器的容量和性能瓶颈问题而采用的一个优化的一个手段，分布式一般来说有两种实现的形式，一种呢，就是水平扩展，当我们一个机器扛不住流量的时候，我们就给它添加机器，把流量呢，平分到我们所有的这些服务器上，这样的话，我们所有的机器就可以提供相当的一个服务，那或者是说呢，我们也可以去进行垂直的这个拆分，也就是说，我们前端如果有多种这个查询这个请求的时候，那一台机器扛不住，我们就可以把不同的这种请求发送到不同的机器上，比如说呢，我们a只查询一种请求，b查询另一种请求，这个呢，即使我们垂直的一个拆分。那什么是高并发呢，对于分布式来讲，高并发它解决问题要更集中一些，比如说呢，它这个高并发就是我们反映的是同时能有多少量，其实呢，高并发它可以用分布式的这个技术去解决，去把并发流量分到我们不同的这个物理服务器上，但是除了这种分布式的解决方式之外呢，高并发还有其他的解决方式，比如说可以用缓存系统，这样的话也可以去解决高并发的一个问题，所以说呢，它俩是有区别联系的，那我们在测试的时候怎么去做呢？高并发，我们是从业务的角度去描述我们系统的一个能力，实现高并发的手段，我们既可以采用分布式，也可以采用什么缓存，什么CDN等等的这些手段，也可以使用多线程的方式，那分布式呢，它是从物力资源的角度去把不同的机器组成一个整体，对外提供服务，这个技术范围呢，就非常广，而且难度比较大，那有了这个基础呢，高并发高吞吐之类的，这个系统就很容易构建了，分布式的这种系统是比较容易构建的，那我们在测试的时候呢，需要关注的就是并发相同参数的请求，看看是不是只有一条请求能够成功，其他请求失败，再有呢，就是我们在分布式的环境当中，并发相同参数的请求，看看是不是只有一条请求成功，其他请求失败，这就是我们这两个线程安全我们要去考虑的。

那数据库读写安全测试是说什么呢，这个数据库读写呢，其实就是要保证我们同时去进行数据操作，也是可以正常去进行的，其实这里呢，就涉及到了数据库锁的一个概念，锁呢，是数据库当中非常重要的一个概念，当多个用户同时对数据库进行并发操作的时候，它其实呢，就可能会带来这种数据不一致的问题，那锁呢，最主要的就是用来在多用户环境下保证我们数据库的一个完整性和一致性，就是说我们有了这个锁之后呢，当我们多个用户并发的去存取数据的时候，那么在数据库当中呢，就会产生多个事务，并且同时存取同一个数据的这种情况，那如果说我们对并发不加操作的话，不加控制的话，那么就可能会造成读取和存储不正确，破坏数据库的一致性，所以说呢，加锁是我们实现数据库并发控制的一个非常重要的一个技术，那当我们到某个事物对我们数据对象进行操作之前，会先向系统去发送请求对它加锁，那加锁之后呢，事务就对这个数据有了一定的控制，那么在这个事务释放这个锁之前呢，其他的事务是不可以对这个数据对象去进行一些更新操作的，那所以说我们在测试的时候呢，就需要同时的去并发的进行数据的更新和插入操作，或者是说，这个同时并发去进行数据的删除和插入操作，看看这些操作是不是都能够正常的执行而互相不影响，所以说大家看这个呢，就是我们测试接口的具体思路了

我们既要保证功能基本流程，还是要去基于每一个输入参数去进行对应的设计，然后呢，我们还需要去考虑我们接口的幂等性，考虑我们接口的一些故障的处理能力，还有呢，就是考虑它的一些线程安全

接口测试用例包含哪些要素：用例名称、接口地址、请求方式、前置条件、请求头部、请求参数、响应状态码、预期响应结果。（和普通功能用例大概一致，但是可能包含一些接口的特有的要素）

下面是配套学习资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！

软件测试面试小程序

被百万人刷爆的软件测试题库！！！谁用谁知道！！！全网最全面试刷题小程序，手机就可以刷题，地铁上公交上，卷起来！

涵盖以下这些面试题板块：

1、软件测试基础理论 ，2、web,app，接口功能测试 ，3、网络 ，4、数据库 ，5、linux

6、web,app，接口自动化 ，7、性能测试 ，8、编程基础，9、hr面试题 ，10、开放性测试题，11、安全测试，12、计算机基础

资料获取方式 ：