接口测试用例编写常见误区

评审新人的接口用例作业时，发现以下一些比较常见的问题，汇总如下：

 

1、遗漏正常用例——不能只把关注点放在异常情况的校验和检查上，正常调用情况、正常参数用例也需要覆盖

2、遗漏头部参数校验——不能只关注body参数的校验，若头部参数中包含需要校验的参数，也需要覆盖

3、等价类划分冗余或无效——参数校验时按照等价类方法设计用例，需要保证等价类的划分是有效、覆盖全面的（能覆盖接口文档需求），同时不要有冗余的用例。

• 避免多个用例重复测试一个类型的校验。
• 避免臆想出来的参数校验类型，设计测试点要基于了解接口功能，不能主观的认为这个参数可能的值会是什么，等到实际构造数据时才发现这种数据不存在，构造不出来。

4、用例细节设计不合理，可复用性低——在参数值里写死取值，但该值的类型受其他影响变动，会废掉这条用例的情况。手动准备参数然后调一次就废掉的用例不是好用例。

提高用例可复用性的方法：

（1）对项目里经常用到的参数的类型取值，进行全局变量配置，用例中使用变量名调用，改动时只改全局配置中的全局变量的值

 

（2）对接口进行前置数据处理，数据实时从数据库取并保存到变量，用例中使用变量调用，结果校验中也使用变量校验，可避免数据改动对接口的影响

（3）对接口进行前置接口调用，数据通过前置接口获取或者构造，用例中使用前置接口构造的数据，每次都重新生成接口所需的数据

5、遗漏接口返回值校验——完全没有对返回进行校验设置，导致无论什么样子的接口返回都显示用例通过

接口的返回需要设置校验，不能只是运行接口后查看结果显示的调用结果，就不管了，那样的用例是没有任何可回归性的，就算接口改动后接口返回内容改变，也完全感知不到

接口返回的校验方法：

（1）校验返回参数，对实际调用返回数据进行预期值判断

 

（2）使用脚本进行断言功能，对返回内容做处理和判断（可校验数据量、db&redis变化、调用另外的查询接口、检查mq等）

补充：使用postman，也可以进行返回结果校验，使用test 接口自动化断言

 

6、遗漏接口状态码校验——接口返回状态也需要检查

此处的接口状态不仅仅指接口自定义的状态参数（类似statusCode），还包括包含HTTP状态码的信息头（server hea

 

 

7、遗漏整体场景用例设计——针对单个参数的校验要做，但是也不要漏掉所有参数合起来的整个整体在接口调用时所处的场景；针对单个接口的校验要做，但是实际调用时涉及多个接口的调用构成一个完整的主功能场景时也要考虑多接口场景设计；

例子：一个新增数据的接口，除了校验接口参数的各种情况，还应该真的考虑这个接口调用后新增的这一条完整的数据在表中会发生的场景（常见重复数据、已删除数据的场景）

 

 

8、弄混参数缺失和参数为空的区别

（1）参数缺失：针对的是有判null(isNotNull)处理的参数，将参数和参数值完全删除或者设置值为null来构造测试用例

（2）参数为空：针对的是有判空(isNotEmpty)处理的参数，将参数值设置为空字符串“”、空list []等来构造测试用例

9、遗漏接口功能的后置校验——当接口调用后，接口返回值不能说明接口功能执行的情况时，还需要另外校验接口后置改动，比如数据表数据变动、mq发送等，可以通过后置条件（db查询、接口查询等）校验接口实际执行后效果。

10、对接口相关的数据存储不了解——接口涉及的数据表、redis设计需要提前了解，否则会影响对接口的测试判断。会遗漏数据校验相关的测试点设计。

11、遗漏接口耗时监控——功能达标后，需要监控接口的基本性能是否符合要求，若耗时超长但功能正常也是不可交付的。在项目送测时需要检查是否配置监控等设置，方便测试时积累监控数据。