接口测试总结及其用例设计方法

 接口测试的总结文档

　　第一部分：主要从问题出发，引入接口测试的相关内容并与前端测试进行简单对比，总结二者以前的区别与联系。但该部分只交代了怎么作和如何作？并无解释为何要作？

　　第二部分：主要介绍为何要作接口测试，并简单总结接口持续集成和接口质量评估相关内容。

 

第一部分：

首先，在作接口测试的过程当中，常常有后端开发会问：

后端接口都测试什么？怎么测的？

后端接口测试一遍 ，前端也测试一遍，是否是重复测试了？

      因而，为了向开发解释上述问题，普及基本的测试常识，特地梳理了接口测试的相关内容以及其与前端测试的区别，使开发团队与测试团队在测试这件上达成基本的共识，提升团队协做效率，从而更好的保证产品质量。

 

而后，咱们试着回答上面的问题：

问题1.1、后端接口都测试什么？

--回答这个问题，咱们能够从接口测试活动内容的角度下手，看一下面这张图，基本反应了当前咱们项目后端接口测试的主要内容：

 

 

 

问题1.二、咱们怎么作接口测试？

　　--因为咱们项目先后端调用主要是基于http协议的接口，因此测试接口时主要是经过工具或代码模拟http请求的发送与接收。工具备不少如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。

 

问题二、后端接口测试一遍 ，前端也测试一遍，是否是重复测试了？

　　--回答这个问题，咱们能够直接对比接口测试和app端测试活动的内容，以下图为app测试时须要覆盖或考虑内容：

 

 

 　　从上面这两张图对比能够看出，两个测试活动中相同的部分有功能测试、边界分析测试和性能测试，其它部分因为各自特性或关注点不一样须要进行特殊的测试，在此不作讨论。接下来咱们针对以上三部分相同的内容再进行分析：

1、基本功能测试：

　　因为是针对基本业务功能进行测试，因此这部分是两种测试重合度最高的一块，开发同窗一般所指的也主要是这部分的内容。

2、边界分析测试：

　　在基本功能测试的基础上考虑输入输出的边界条件，这部份内容也会有重复的部分（好比业务规则的边界）。可是，前端的输入输出不少时候都是提供固守的值让用户选择（以下拉框），在这种状况下测试的边界范围就很是有限，但接口测试就不存在这方面的限制，相对来讲接口能够覆盖的范围更广，一样的，接口出现问题的几率也更高。

 3、性能测试：

　　这个比较容易区分，虽然都须要作性能测试，但关注点确大不相同。App端性能主要关注与手机相关的特性，如手机cpu、内存、流量、fps等。而接口性能主要关注接口响应时间、并发、服务端资源的使用状况等。两种测试时的策略和方法都有很大区别，因此这部份内容是须要分开单独进行测试的，理论上来讲这也是不一样的部分。

 

综论：

      一、接口测试和app测试的活动有部分重复的内容，主要集中在业务功能测试方面。除此以外，针对各自特性的测试都不同，须要分别进行有针对性的测试，才能确保整个产品的质量。

　　二、接口测试能够关注于服务器逻辑验证，而UI测试能够关注于页面展现逻辑及界面前端与服务器集成验证

  

第二部分：

1、什么是接口测试？

      接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

 

2、为何要作接口测试?

　　a) 现在的系统复杂度不断上升，传统的测试方法成本急剧增长且测试效率大幅降低，接口测试能够提供这种状况下的解决方案。

　　b)  接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，能够减小人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为何能低成本高收益的根源。

　　c)   如今不少系统先后端架构是分离的，从安全层面来讲：

     　　 一、只依赖前端进行限制已经彻底不能知足系统的安全要求（绕过前面实在太容易）， 须要后端一样进行控制，在这种状况下就须要从接口层面进行验证。

     　　 二、先后端传输、日志打印等信息是否加密传输也是须要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。

 

3、接口测试持续集成：

      对接口测试而言，持续集成自动化是核心内容，经过持自动化的手段咱们才能作到低成本高收益。目前咱们已经实现了接口自动化，主要应用于回归阶段，后续还须要增强自动化的程度，包括但不限于下面的内容：

　　a) 流程方面：在回归阶段增强接口异常场景的覆盖度，并逐步向系统测试，冒烟测试阶段延伸，最终达到全流程自动化。

　　b) 结果展现：更加丰富的结果展现、趋势分析，质量统计和分析等

　　c) 问题定位：报错信息、日志更精准，方便问题复现与定位。

　　d) 结果校验：增强自动化校验能力，如数据库信息校验。

　　e) 代码覆盖率：不断尝试由目前的黑盒向白盒下探，提升代码覆盖率。

　　f) 性能需求：完善性能测试体系，经过自动化的手段监控接口性能指标是否正常。

 

4、接口测试质量评估标准：

　　a) 业务功能覆盖是否完整

　　b) 业务规则覆盖是否完整

　　c) 参数验证是否达到要求（边界、业务规则）

　　d) 接口异常场景覆盖是否完整

　　e) 接口覆盖率是否达到要求

　　f)  代码覆盖率是否达到要求

　　g) 性能指标是否知足要求

　　h) 安全指标是否知足要求

 

接口测试用例设计

1、    用例设计过程：

罗马不是一天建成的，用例不是一次完成的；书写测试用例自己和完善代码同样，也是一个按部就班的过程。

 

首先，必须熟读需求说明书和接口设计文档，了解每一个接口具体的使用场景，明白软件的性能指标。

 

其次，设计接口测试用例：开始在编码阶段，测试人员根据需求说明书和接口设计文档设计接口测试用例。

 

而后，code review：开发完成编码后，在时间充裕的条件下，要进行 code review，一方面是检查开发的代码功能逻辑是否正确，另外一方面经过review开发的代码来补充接口测试用例。

 

      最后，完成用例后，随着对系统了解的增多，不断提升用例精度，对测试用例须要进行按期review，一旦测试需求发生变化，测试用例必须从新维护。

 

2、接口测试用例构思结构：

 

阶段一：开发在编码，测试拿到需求文档和接口设计文档：

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

 

一、      review开发的代码实际业务逻辑是否正确

2、隐含条件测试：

进行code review，检查代码中是否有隐含的默认条件。例如：F项目中的getRecommendArticleList接口，代码中默认查询返回4条记录（以下图），但在接口文档中并未提到，若是不review code而开发也不告诉咱们的话，这种状况确定会漏测。

 

 

 

 

3、SQL测试：

针对须要进行数据库操做的接口，查看相关sql，对sql的正确性进行验证。以下图，通常sql的过滤条件都会比开发告诉咱们的要多，因此查看sql进行验证是最保险的方式，特别须要设计组合条件的场景进行验证：

 

 

 

 

 

3、测试过程验证点：

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)         并发承载能力：多用户并发时接口能够承载合同中的并发量。