测试需要关注的测试点以及测试优先级（一）——接口测试
1、接口测试的测试点以及优先级
无论是app测试还是web测试，又或者是纯服务端测试，接口测试都是必须要掌握的。接口无处不在，无论你测试时看到的界面是什么，其内涵都是要靠接口进行连通。
1.1、什么是接口
百度百科的专业解释：
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
简单来说，接口就是定义了标准的规则（输入参数和输出结果）
1.2、接口的场景分类
（1）独立系统A与独立系统B之间的数据交换过程
如：微信、微博所提供的第三方登录接口，是不同公司之间系统接口的调用
（2）一个系统之间的不同层
常见的java-web项目都是分为：web层、dao数据层以及service服务层，这三层之间就是通过接口进行数据交互的
（3）系统内，服务与服务之间的调用
也就是各个模块之间的相互调用
1.3、测试接口前的准备工作
明白了什么是接口，也明白了哪些场景下需要展开接口测试工作，我们就要准备接口测试工具，要想选择出合适的测试工具，必须清楚的知道负责测试的接口采用的协议是什么，因为只有知道接口采用的协议是什么，才能明白它采用的协议是否属于应用层。应用层代表的协议http，只有http的协议，才能采用常见的测试工具如postman、jmeter等去测试。
如果接口采用的协议并不属于应用层，例如阿里巴巴的dubbo，此时你就不能直接采用postman、jmeter去测试。
总之接口测试前最重要的准备工作就在于了解接口采用的协议是哪个。
1.4、接口测试分层模型
针对接口，将接口测试抽象成四层模型，具体如下：
（1）接口文档测试
（2）内部业务逻辑测试
（3）数据库存储测试
（4）其他异常流测试
展开来说：
1.4.1、基础接口文档的验证
对于接口测试来说，接口文档是双方接口得以联通的基础，也是数据能否正常传输的依赖标准，完成接口文档的测试，可以说接口测试就已经完成了大半。
从接口文档中我们应该提炼出以下测试点：
（1）首先明确请求的数据类型是什么，目前主流是json串，那么就要清晰的识别出接口文档中哪些是key-value键值对，哪些是内嵌的json数组，哪些是内嵌的json对象，只有这样你才能组织出有效的测试数据。
（2）对接口文档中定义的必录项一一进行测试，看某必录项缺失时，作为接收的一方是否有合理提示。
（3）对于文档中定义的非必录项一一进行测试，看某非必录项缺失时，作为接收的一方是否可以正常接收信息。
（4）对于特殊字段的测试。
例如日期，需要明确以下测试点：
①需要的日期类型是Date类型还是String类型。
②需要的日期格式是时间戳还是YYYYMMDD或者YYYYMMDDHHMMSS的格式。
（5）对于有效数字保留进行测试。
一般接口文档要求保留最多两位小数，此时要验证整数、保留一位小数、保留两位小数、保留三位小数时接收方的响应。（即边界值方法测试）
（6）对于常见的身份证号、手机号、座机号等特殊标的信息要进行长度、有效性、容错性测试。
①针对身份证号：要注意最多支持18位，且必须保证身份证号正常，且注意以 X 结尾的身份证号系统是否支持。
②针对座机号：要注意支持的格式包含哪些，一般要支持：010-6656667、 0106656667、 0314-8876551、 03148876551、 (010)6656667等多个格式。
（7）对于枚举值，要一一进行测试。（运用等价类划分的方法）
（8）针对特殊定义类型的测试。
例如：有些接口中定义的字段类型为 int，且是必输，此时就有陷阱在里面，因为当不传数据时，java 默认的 int 类型就是 0，此时不传与传 0 就是同样的现象。
1.4.2、内部业务逻辑测试
此模块要求我们基于各种业务场景，测试其接口的内部逻辑。因为针对业务不同，具体逻辑也五花八门，我只概括的进行总结，然后根据自己测试的接口展开扩展。
（1）遇到时间，要确认各种业务场景下是否有因为时间而影响的场景。
举例一：我们遇到身份证号，判定其满足身份证生成规则，还要看这个证件是否在有效范围内；
举例二：我们遇到类似还款的场景，是否发起还款的时间已经逾期。
（2）遇到金额想到是否存在等式和不等式的关系。
举例：支付宝的花呗还款，应该注意以下场景：
①当前还款总金额=当前还款本金+当期还款利息（等式成立）
②提前还款总金额必录且大于0（不等式成立）的金额，不能还负数
（3）遇到运维阶段的需求改动，一定要想到历史数据的处理。
举例：银行借款：银行答应借款人的借款期限是3个月，后来业务收缩，决定缩小期限变为2个月.那么已经按照3个月借款的借款人怎么办？肯定还是按照3个月期限进行还款。此时就需要我们的程序一定要兼容历史数据也要适用于新数据。测试时必须考虑这一点。
（4）独立存在的逻辑场景。
这个需要切实根据自己测试的功能进行总结，建议可以将这部分建立自己的质量地图，后期维护时肯定会事半功倍。
（5）地域划分逻辑。
许多接口需要采集信息，是否对港澳台等特殊地区有特殊要求。
（6）不同业务接口见的数据枚举转化。
举例：在自己的接口文档中，性别使用M、F来代表男、女。但是和合作方的接口中，却用数字1、2表示，此时我们设计用例要覆盖转化关系。
总的来说，如果说“基础接口文档的验证”依赖的是接口文档，那么此层级的测试则更关注与需求和业务。
1.4.3、数据库相关测试
针对接口测试，最终还要确保数据正确落库，主要需要关注如下测试点：
（1）接口完成会插入哪些业务表
（2）接口完成会更新哪些表的哪些字段
1.4.4、其他异常流测试
前三部分可以说测试用例都是围绕正常流展开的，本层级需要重点关注异常流，具体需要从如下方面进行测试用例的设计展开。
（1）密等性测试
主要针对如下场景：A调用B，此时发生超时或者断网等异常，此时B已经接收但是却没有返回给A，A再次调用此时B的处理逻辑。
（2）流程节点测试
例如：本来程序的正常流转应该是 A->B->C，此时我们跳过B节点，直接从 A 流转到 C 程序是否有良好的校验。
（3）数据库事务性测试
有些重要的业务流程，可能涉及操作多个数据库中的表，当中间执行失败时，数据库是否可以回滚以保持数据的准确。
异常测试还有很多，上述列举出来的属于最经典的部分。
1.5、测试优先级
上述的四个层面都属于重点测试模块，优先级高，针对一个接口应该将上面的四个层级都覆盖掉才能保证接口测试的完备。
