接⼝测试总结及其⽤例设计⽅法
接⼝测试的总结⽂档
  第⼀部分：主要从问题出发，引⼊接⼝测试的相关内容并与前端测试进⾏简单对⽐，总结两者之前的区别与联系。但该部分只交代了怎么做和如何做？并没有解释为什么要做？
  第⼆部分：主要介绍为什么要做接⼝测试，并简单总结接⼝持续集成和接⼝质量评估相关内容。
第⼀部分：
⾸先，在做接⼝测试的过程中，经常有后端开发会问：
后端接⼝都测试什么？怎么测的？
后端接⼝测试⼀遍，前端也测试⼀遍，是不是重复测试了？
于是，为了向开发解释上述问题，普及基本的测试常识，特意梳理了接⼝测试的相关内容以及其与前端测试的区别，使开发团队与测试团队在测试这件上达成基本的共识，提⾼团队协作效率，从⽽更好的保证产品质量。
然后，我们试着回答上⾯的问题：
问题1.1、后端接⼝都测试什么？
--回答这个问题，我们可以从接⼝测试活动内容的⾓度下⼿，看⼀下⾯这张图，基本反应了当前我们项⽬后端接⼝测试的主要内容：
问题1.2、我们怎么做接⼝测试？
  --由于我们项⽬前后端调⽤主要是基于http协议的接⼝，所以测试接⼝时主要是通过⼯具或代码模拟http请求的发送与接收。⼯具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
问题2、后端接⼝测试⼀遍，前端也测试⼀遍，是不是重复测试了？
  --回答这个问题，我们可以直接对⽐接⼝测试和app端测试活动的内容，如下图为app测试时需要覆盖或考虑内容：
  从上⾯这两张图对⽐可以看出，两个测试活动中相同的部分有功能测试、边界分析测试和性能测试，其它部分由于各⾃特性或关注点不同需要进⾏特殊的测试，在此不做讨论。接下来我们针对以上三部分相同的内容再进⾏分析：
1、基本功能测试：
  由于是针对基本业务功能进⾏测试，所以这部分是两种测试重合度最⾼的⼀块，开发同学通常所指的也主要是这部分的内容。
2、边界分析测试：
  在基本功能测试的基础上考虑输⼊输出的边界条件，这部分内容也会有重复的部分（⽐如业务规则的边界）。但是，前端的输⼊输出很多时候都是提供固守的值让⽤户选择（如下拉框），在这种情况下测试的边界范围就⾮常有限，但接⼝测试就不存在这⽅⾯的限制，相对来说接⼝可以覆盖的范围更⼴，同样的，接⼝出现问题的概率也更⾼。
3、性能测试：
  这个⽐较容易区分，虽然都需要做性能测试，但关注点确⼤不相同。App端性能主要关注与⼿机相关的特性，如⼿机cpu、内存、流量、fps等。⽽接⼝性能主要关注接⼝响应时间、并发、服务端资源的使⽤情况等。两种测试时的策略和⽅法都有很⼤区别，所以这部分内容是需要分开单独进⾏测试的，理论上来说这也是不同的部分。
综论：
1、接⼝测试和app测试的活动有部分重复的内容，主要集中在业务功能测试⽅⾯。除此之外，针对各⾃特性的测试都不⼀样，需要分别进⾏有针对性的测试，才能确保整个产品的质量。
  2、接⼝测试可以关注于服务器逻辑验证，⽽UI测试可以关注于页⾯展⽰逻辑及界⾯前端与服务器集成验证
第⼆部分：
1、什么是接⼝测试？
接⼝测试是测试系统组件间接⼝的⼀种测试。接⼝测试主要⽤于检测外部系统与系统之间以及内部各个⼦系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
2、为什么要做接⼝测试?
  a) 如今的系统复杂度不断上升，传统的测试⽅法成本急剧增加且测试效率⼤幅下降，接⼝测试可以提供这种情况下的解决⽅案。
  b)  接⼝测试相对容易实现⾃动化持续集成，且相对UI⾃动化也⽐较稳定，可以减少⼈⼯回归测试⼈⼒成本与时间，缩短测试周期，⽀持后端快速发版需求。接⼝持续集成是为什么能低成本⾼收益的根源。
app接口测试工具  c)  现在很多系统前后端架构是分离的，从安全层⾯来说：
  1、只依赖前端进⾏限制已经完全不能满⾜系统的安全要求（绕过前⾯实在太容易），需要后端同样进⾏控制，在这种情况下就需要从接⼝层⾯进⾏验证。
  2、前后端传输、⽇志打印等信息是否加密传输也是需要验证的，特别是涉及到⽤户的隐私信息，如⾝份证，银⾏卡等。
3、接⼝测试持续集成：
对接⼝测试⽽⾔，持续集成⾃动化是核⼼内容，通过持⾃动化的⼿段我们才能做到低成本⾼收益。⽬前我们已经实现了接⼝⾃动化，主要应⽤于回归阶段，后续还需要加强⾃动化的程度，包括但不限于下⾯的内容：
  a) 流程⽅⾯：在回归阶段加强接⼝异常场景的覆盖度，并逐步向系统测试，冒烟测试阶段延伸，最终达到全流程⾃动化。
  b) 结果展⽰：更加丰富的结果展⽰、趋势分析，质量统计和分析等
  c) 问题定位：报错信息、⽇志更精准，⽅便问题复现与定位。
  d) 结果校验：加强⾃动化校验能⼒，如数据库信息校验。
  e) 代码覆盖率：不断尝试由⽬前的⿊盒向⽩盒下探，提⾼代码覆盖率。
  f) 性能需求：完善性能测试体系，通过⾃动化的⼿段监控接⼝性能指标是否正常。
4、接⼝测试质量评估标准：
  a) 业务功能覆盖是否完整
  b) 业务规则覆盖是否完整
  c) 参数验证是否达到要求（边界、业务规则）
  d) 接⼝异常场景覆盖是否完整
  e) 接⼝覆盖率是否达到要求
  f)  代码覆盖率是否达到要求
  g) 性能指标是否满⾜要求
  h) 安全指标是否满⾜要求
接⼝测试⽤例设计
⼀、⽤例设计过程：
罗马不是⼀天建成的，⽤例不是⼀次完成的；书写测试⽤例本⾝和完善代码⼀样，也是⼀个循序渐进的过程。
⾸先，必须熟读需求说明书和接⼝设计⽂档，了解每个接⼝具体的使⽤场景，明⽩软件的性能指标。
其次，设计接⼝测试⽤例：开始在编码阶段，测试⼈员根据需求说明书和接⼝设计⽂档设计接⼝测试⽤例。
然后，code review：开发完成编码后，在时间充裕的条件下，要进⾏ code review，⼀⽅⾯是检查开发的代码功能逻辑是否正确，另⼀⽅⾯通过review开发的代码来补充接⼝测试⽤例。
最后，完成⽤例后，随着对系统了解的增多，不断提⾼⽤例精度，对测试⽤例需要进⾏定期review，⼀旦测试需求发⽣变化，测试⽤例必须重新维护。
⼆、接⼝测试⽤例构思结构：
阶段⼀：开发在编码，测试拿到需求⽂档和接⼝设计⽂档：
1、基本功能测试（业务测试）：
根据需求⽂档和接⼝设计⽂档的转译，需要清楚业务流程规则和每个接⼝的使⽤场景⽅式，设计符合业务逻辑和接⼝使⽤场景的⽤例。
2、边界分析测试：
在基本功能的基础上，开始考虑接⼝输⼊输出参数的影响。主要采⽤等价类划分、边界值分析⽅法等。
l  覆盖所有的必选参数
l  组合可选参数
l  参数有⽆、或为null
l  参数的顺序、个数、类型
l  参数类型数值⼤⼩、输⼊的数值的范围
l  参数字串长短，Null-max-max+1
l  参数包含特殊字符
3、参数组合测试：
在边界分析的基础上，考虑输⼊条件的各种组合、输⼊条件之间的相互制约关系。主要使⽤因果图法进⾏⽤例设计。
4、异常情况测试：
接⼝实现是否对异常情况都进⾏了处理，接⼝输⼊参数虽然合法，但是在接⼝实现中，也会出现异常，因为内部的异常不⼀定是输⼊的数据造成的，⽽有可能是其他逻辑造成的，程序需要对任何异常都进⾏处理，⽐如：某个接⼝需要先登录获取 sesssion，如果直接调⽤该接⼝应该给出相应提⽰。
5、幂等级测试：
简单说就时针对连续重复提交的情况的进⾏测试，特别是涉及到交易⾦额的场景，需要验证软件是如何处理的。
6、并发测试：
两个以上⽤户同时操作使⽤同⼀场景时，可能引导争夺资源，死锁等现象。
7、事务性测试：
⼀个业务流程包含多个操作步骤，如果某个操作失败，那么整个操作需要回滚。或者调⽤前⼀个步骤的逆向接⼝进⾏操作取消。
8、⼤数据量时测试
数据库⾥数据量较⼤时（百万级），测试对DB进⾏增删改查操作的效率。
9、环境异常测试
关联系统出现宕机、超时或者⽆响应的状态时，接⼝返回提⽰正确，业务逻辑正确，不可存在事务性不⼀致的情况
阶段⼆：开发完成编码，测试时间充裕的条件下，需要对开发的代码进⾏code review
1、      review开发的代码实际业务逻辑是否正确
2、隐含条件测试：
进⾏code review，检查代码中是否有隐含的默认条件。例如：F项⽬中的getRecommendArticleList接⼝，
代码中默认查询返回4条记录（如下图），但在接⼝⽂档中并未提到，如果不review code⽽开发也不告诉我们的话，这种情况肯定会漏测。
3、SQL测试：
针对需要进⾏数据库操作的接⼝，查看相关sql，对sql的正确性进⾏验证。如下图，⼀般sql的过滤条件都会⽐开发告诉我们的要多，所以查看sql进⾏验证是最保险的⽅式，特别需要设计组合条件的场景进⾏验证：
三、测试过程验证点：
1、接⼝返回数据
a)        返回json数据的层次关系是否与⽂档⼀致
b)        数值类型数据: 特别是⾦额，负数、⼩数转为json输出是否正确
c)        接⼝返回数据与接⼝⽂档⼀致
d)        接⼝返回数据和数据库⼀致
e)        接⼝返回数据符合业务逻辑（⽐如转账功能，从⼀个账户扣款，另⼀个要增加相应⾦额）
f)          对于列表，应该根据请求参数，也应该验证列表的长度是否与期望值⼀致
g)        负⾯测试⽤例，应验证ERROR INFO是否与实际相匹配
2、数据库
a)        接⼝传⼊数据与插⼊DB的数据⼀致性：
b)        前端某个操作涉及后台DB多张表时，每张表都要检验数据正确性。
3、安全层⾯：
a)        后端接⼝返回给前端的数据包含敏感信息（如：姓名、⾝份证号、卡号、⼿机号、加密后的密码等）时，不能明⽂传输，需要加密。
b)        后台打⽇志要求对于敏感信息不能打出，或者进⾏加星号脱敏后打出，具体有：
1）⾝份证号，⽤户密码（含加密后），⽤户⼿机号码，⽤户姓名，银⾏卡号
2）⾝份证号码脱敏字段为⽣⽇时，⽣⽇在⽇志中不能打出
4、性能层⾯：
a)        接⼝响应时间：接⼝处理数据的时间也是测试需要关注的⼀个点。牵扯到内部就是算法与代码的优化
b)        接⼝数据包⼤⼩：接⼝传递的数据包⼤⼩也需要关注，特别是返回给前端的接⼝，要把不同接⼝数据包⼤⼩需要做限制。
c)        并发承载能⼒：多⽤户并发时接⼝可以承载合同中的并发量。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。