接口测试用例设计

一、功能性用例设计

之前讲过，服务端的接口是和客户端的功能相对应的，对功能的验证，可以参照接口说明文档来进行。概括起来讲，就是我们需要验证接口说明文档中提到的各种情况，保证这些情况下接口的返回和最初设计的是一样的，这样我们就可以认为该接口实现了功能需求。

举个例子，目前有一个接口A，关于该接口的请求参数列表如下：



 

可以看到，规定该接口的请求类型是get，同时该接口包含4个请求参数，那么在功能性的用例设计上，我们可以考虑如下几个方面： 

1.以get方式请求； 

2.请求中需要包含这4个参数； 

3.各个参数的类型符合要求； 

4.key参数的长度需要控制在10个字符以内。

通过这几个方面写出来的case就是功能性的测试用例了。其实不难看出，功能性测试用例的目的是为了验证服务端在正常情况下是否实现了需求，因此构造出的用例都是满足接口说明文档的要求，即验证在正常情况下，客户端传入正常的参数后，服务端可以正常响应。

二、业务逻辑用例设计

业务逻辑方面的用例设计与功能性用例设计不同，逻辑用例主要关注接口内的各种判断对应的逻辑分支是否符合预期，这种用例不是针对某个具体的功能点，而是去验证接口内部的各种处理逻辑。这类用例，往往需要以业务逻辑流程图为依据进行设计。 

举个例子，在小编最近测试的项目中，画出接口流程图后有这样的一个逻辑：

 


 

可以看到这一块有两个判断，那么 针对这一块儿的处理逻辑，我们需要对不同的判断分支都设计用例，以保证流程图中涉及到的分支我们都有测试用例覆盖。图中涉及到的不同的分支有： 

1.abdf； 

2.acg; 

3.abdeg; 

相应的，我们的用例就应该是： 

1.userInfo != null && value(userGroup) != 0; 

2.userInfo == null; 

3.userInfo != null && value(userGroup) == 0; 

业务逻辑的用例设计主要是以服务端接口内部的逻辑流程图为基础，针对流程图中的判断和分支进行用例设计，保证服务端接口的每一种逻辑下都有测试用例覆盖。

三、异常处理的情况

由于客户端与服务端接口之间通常是通过HTTP请求来进行交互获取数据，因此对于请求中携带的参数以及数据的容错处理是必须考虑的一类case。关于异常处理我们可以归为两大类：参数异常和数据异常。具体而言常见的异常类型有以下几种：缺省或增加参数、参数类型不对、参数为空、数据超过限制等等。我们还是用接口A的参数来举例：



 

接口A的请求中一共有4个参数；那么异常情况可以这样去考虑： 

1.多了一个/若干个参数，比如请求中又携带了一个v=1这样的参数； 

2.缺省了某个参数，比如请求中不带page参数； 

3.参数类型不对，比如isMob规定是boolean类型，可以尝试传递一个其他的类型； 

4.数据为空，比如我们可以令key=(null)，发送请求后检查服务端的响应； 

5.数据超过限制，比如在接口文档中规定key的长度不超过10个字符，那么我们需要设计可以覆盖到边界值的用例，比如长度为9、10、11等。 

…… 

值得注意的是，在功能均已实现的时候，对服务端而言容错非常重要，如果容错做得不好，往往可能一个格式不正确的参数就会引起服务端的异常甚至崩溃，因此在设计用例的时候，异常用例需要格外注意，需要尽可能多的设计出包含各种异常的用例，至少保证服务端在请求异常的情况下不会出现崩溃等极端状况。

四、性能和安全性方面

在进行服务端测试的时候，性能和安全性方面的用例是必须要考虑的。服务端的性能测试往往与功能性测试分开执行，一般情况下在服务端的功能测试进行完毕保证功能上没有问题的情况下，可以进行性能测试。性能测试借助于一些工具开展，比如LoadRunner等，关于性能测试，在后续的分享中我们会为大家详细介绍。安全性方面，主要需要考虑一些常见的安全策略，举个例子，在请求中需要携带用户的敏感信息（比如电话号码、身份证号码、地址信息等）时，敏感信息一定是需要加密的，需要验证对这些数据加密的生效性；又比如，在上面的接口A中，我们可以在参数中传一段JS代码，看服务端如何处理……

以上向大家介绍了服务端用例设计常见的几个方面，希望可以给各位测试小伙伴在平时的用例设计中提供一点帮助。大家如果有什么好的思想和方法，也可以进行留言互动。在以后的文章中，我们会继续就服务端测试相关的思想、方法、工具使用以及流程规范等和大家共同探讨，敬请大家持续关注。