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