接口测试标准及规范
1.后端服务产品接口测试说明
后端服务性产品基本上都是以API的形式对外提供服务，所以其最重要的一个测试类型就是接口测试。
对测试人员的要求
接口测试要求有较好的编码水平，测试代码才能更简洁、高效。接口测试既要求对系统的整体架构有足够的了解，又要求对用户场景熟悉，两者相辅相承。要求从白盒角度了解系统设计，从黑盒角度设计测试场景，注重两者之间的权衡。
2接口测试的优缺点
对于后台产品，接口测试作为最重要的一个测试类型，基本上是必由之路。所以，这里无需探讨要不要引入接口测试的问题，而是直接探讨接口测试的优缺点即可。
2.1接口测试优势
后台基础服务的架构往往很复杂，而接口测试可以让测试人员集中精力关注系统对外交互的部分，因而能够提供系统复杂度上升情况下的低成本高效率的解决方案。相比单元测试，接口测试是站在用户的角度对系统接口进行全面高效持续的检测。接口测试能高效完成手工测试比较难覆盖的场景，比如上传100个文件等。容易转型到性能测试和稳定性测试，因为性能测试是基于接口来进行场景设计的，所以接口测试人员做性能测试在技术层面是比较方便的。
2.2接口测试不足
接口测试运行速度相对于单元测试要慢得多
比如单元测试执行时间控制在5分钟之内很容易
接口测试如果是针对复杂系统，全量测试往往要几个小时。
所以在持续集成中，要注意权衡测试的覆盖和执行的速度之间的关系。
接口测试需要的测试环境比较复杂单元测试可以不依赖数据库、文件系统等
接口测试需要的是一个完整的测试环境，并要求尽可能和产生环境一致，这对于复杂性来说，有时候一个独立的测试环境是比较困难的。
如果要对系统进行mock，也不如单元测试那么方便。
接口测试的粒度较粗
以接口为最小的粒度，这样的粒度相对单元测试就属于粗粒度，容易造成一定的测试遗漏
需要测试和开发人员共同评审用例，必要时需要分析测试覆盖情况来补充测试用例。
接口返回值做为校验条件有风险
接口本身可能存在bug，在使用接口返回值做为校验条件时有较高的风险，必须辅助其他的校验方式，比如数据库查询、操作系统状态等。
例1，测试RDS扩容接口时，接口返回了扩容成功，但是实际上从操作系统用df命令查看磁盘容量还是原来的大小。
例2，创建一个云主机的接口调用，接口返回成功后，还需要真的登录到这台机器上（通过ssh或者VNC），才能认为这台主机创建成功了。
接口测试并不能全面保证产品质量
接口测试的覆盖范围有限，需要结合单元测试，共同提高测试覆盖率
接口测试不关注性能和稳定性，在项目初期应该考虑这方面的影响。
接口测试更多的关注正常逻辑和参数异常，对系统级异常需要更多的关注。
3．工具及测试形式
后台项目接口一般分HTTP接口和Dubbo接口两种，从接口测试的角度来看，两者区别不大。测试用例书写一般采用有如下方式：
直接采用程序编写测试代码（Java、Python等），并且基于已有的测试框架，比如TestNG和UnitTest。用工具录制或者组装接口请求（Jmeter、Postman等）。如果是HTTP请求，则采用requests；如果是dubbo接口，则直接调用Hessian。文件解析方式没有采用上面接口方式，单独设计框架进行解析处理。
4．接口测试用例设计方法
4.1场景覆盖
场景覆盖，是从用户角度进行设计的测试覆盖。主要是模拟用户的业务操作，达到对用户行为的覆盖。场景覆盖是后端基础服务接口测试中最重要的覆盖。
例如，用户对云主机的使用，会涉及到创建云主机、创建用户密钥、修改安全组、通过SSH客户端登陆到云主机、执行用户操作5个步骤。如果只是单纯的接口测试，对后面两个步骤容易忽略，虽然对系统来说资源可以分配成功，但是可能造成用户无法登录云主机，造成非常严重的影响。
4.1.1场景收集
需求文档中定义的usecase，也可以适当的延伸和扩展。接口使用方的使用场景，比如云主机提供给RDS的接口，RDS是如何调用的。每次云主机的接口修改，会不会影响到RDS的使用。
产品用户的使用场景，比如云主机的用户是运维人员，需要对运维人员的使用习惯，操作频率做收集和整理，增加到测试场景中。
线上bug，针对线上bug要做专门的分析，是否需要增加到测试场景中。他途径的用户反馈，比如邮件列表、POPO群讨论，反馈系统等。
4.1.2场景覆盖
测试场景要覆盖用户的关键使用场景，在测试设计阶段要需要让用户参与评审。
场景测试和参数测试允许有部分重叠。
场景测试优先覆盖正常路径，其次是分支路径以及异常路径。
场景需要分组，比如分成冒烟测试、主干功能测试、异常测试、参数测试等不同的分组，根据需要选择其中的部分进行评审、执行。
测试场景保持独立性和原子性，每个测试场景完成独立的功能，不受其他操作的影响。
4.2接口参数覆盖
接口测试是通过输入使用参数组合，获得服务器返回值，并根据预先设定的规则判断是否符合预期值。所以接口测试中，参数的覆盖非常重要。
比如，一个上传文件到网盘的操作接口
uploadFile(Stringusername, String dir, String filename, int length, boolean isPublic)
参数的含义分别为：
username：用户名，字符型，取值范围：6---100字符。
dir：文件存放的目录名，字符型，取值范围：不限。
filename：上传的文件名，字符型，取值范围：1---255字符。
length：文件长度，整型，取值范围：1---65535。
isPublic：是否公开显示此文件，布尔型，取值为True/False。
FileInfo：返回上传的文件描述信息。
参数类型
数值型：包括整型、浮点型，比如文件长度、距离、重量等。
字符型：英文、中文字符串，比如姓名、账号等。
布尔型：True / False。
枚举型：一组基本类型的列表，比如学历=[qa:本科以下、本科、硕士、博士]。
组合类型：List、Map、json等。
单值覆盖
随机型：在指定范围或指定长度内任意取值，比如一个整数取值在0-65535、长度为10的字符串.
枚举型：依次取每一个值，比如性别（男、女）、快递地址的省、市、区。
边界值：对取值范围内的最大、最小、最大+1、最小-1取值。
异常值：null、类型最大值和最小值、空字符。
默认值：对某些非必选参数，采用默认值。
非法值：类型不匹配、超出类型范围、超出操作系统限制、系统关键字
参数组合覆盖
参数组合：采用笛卡尔积的全组合策略。比如3个参数，每个参数有5种取值，组合起来就有5x5x5=125个测试用例，优点是覆盖全面，缺点是组合数量巨大，工作量大。
全对偶组合：保证每个参数和其他参数都有组合出现，即采用尽可能少的组合覆盖尽可能对的参数。覆盖性价比很高。比如上述的参数组合，大约只需25个用例即可覆盖。
单点失效：单个参数使用非法或异常值，其他值保持正常取值。
多点失效：多个参数使用非法或异常值，其他采用正常取值。
5接口测试最佳实践
5.1测试断言的设计
测试断言是自动化测试中的测试通过条件，用于判断测试用例是否符合预期。断言是单元测试xUnit框架的核心，最早是一般都通过Assert类的静态方法提供。这里要讲的断言，是单元测试和接口测试中用到的，不是用在开发代码中的。
断言的形式
让断言去比较，输入原始数据
assertEquals（expected,
actual, message）
自己做比较，输入布尔表达式
assertTrue/assertFalse（boolean,
message）
断言设计原则
形式保持统一
使用了assertTrue，就不要再使用assertFalse，保持一致性。
不要混用unittest和其他框架断言。
使用明确的message
尽量选择带message参数的断言方法
可以使断言结果的可读性更强。
使得测试代码可读性更强。
断言不要放在公共方法中
公共方法只处理通用逻辑，不处理验证逻辑。
断言让验证只存在于业务逻辑代码中。
不要使用恒对错的断言
比如assertTrue（true）类似这样的断言很可能让你遗漏掉重要的断言。期望返回异常
这种情况不使用raise，因为会抛出异常。
5.2接口测试分组策略
为什么分组
测试执行失败后可以迅速定位问题，并且重试执行不会影响其他分组。提高持续集成反馈速度，对冒烟测试、回归测试区分不同的分组，有的放矢。分组可以任意组合、排除，便于执行不同的组合测试场景。
怎样分组
根据测试粒度区分，冒烟测试、主干功能、全回归测试。
根据功能模块划分，比如创建模块、查询模块、清理模块等。
根据功能是否正常：正常用例、异常用例。
5.3测试结果分析
测试结果
一般的测试框架，都会生成一份完整的测试结果报告。报告一般分为三个部分：
摘要信息
项目地址
测试环境
测试结果汇总
例执行成功、失败情况
用例执行时间统计
用例的分组统计
测试结果详情
每个用例的执行详情，包括方法名、请求参数列表
每个用例的执行时间
测试结果分析
优化执行时间
如果某个分组、用例执行时间过长，需要进行优化调整。
及时处理失败用例
对skip、failed用例，要及时处理，该修改的修改，该移除的移除，不要容忍失败的用例存在于持续集成过程中。
网友评论