接⼝测试⽤例设计的⽅法
导语
  随着分析和分层测试的深化，“”出现在我们视野的频次越来越⾼。那么接⼝测的常⽤哪些⽅法呢？本⽂将详细描述。
  1  接⼝测试
  1.1  接⼝测试
  接⼝：主要是⼦模块或者⼦系统间交互并相互作⽤的部分。
  这⾥说的接⼝是⼴义的，客户端与后台服务间的协议；插件间通信的接⼝；模块间的接⼝；再⼩到⼀个类提供的⽅法；都可以理解为接⼝。
  接⼝测试：是指针对模块或系统间接⼝进⾏的测试。
  1.2  接⼝测试发现的典型问题
  接⼝测试经常遇到的bug和问题，如下：
  （1）传⼊参数处理不当，导致程序crash；
  （2）类型溢出，导致数据读出和写⼊不⼀致；
  （3）因对象权限未进⾏校验，可以访问其他⽤户敏感信息；
  （4）状态处理不当，导致逻辑出现错乱；
  （5）逻辑校验不完善，可利⽤获取⾮正当利益等。
  2  接⼝测试⽤例设计
  上图为⼀个典型的接⼝。⼀个接⼝通常是有输⼊输出的，输⼊就是我们常见的⼊参，输出有时有，有时没有。调⽤相关接⼝，接⼝会执⾏相关处理逻辑。
  接⼝测试的⽤例设计，主要从输⼊和接⼝处理两⽅⾯考虑：
  1）针对输⼊，可按照参数类型进⾏设计；
  2）针对接⼝处理，可按照逻辑进⾏⽤例设计；
  3）针对输出，可根据结果进⾏分析设计。
  2.1  针对输⼊设计
  对于接⼝来说，输⼊就是⼊参。常见参数类型有:
  （1）数值型(int,long,float,double等）
  （2）字符串类型
  （3）数组或链表
  （4）结构体
  结构体(struct)是⼀些元素的结合，元素实际也是数值型，字符串型，数组或链表。
  下⾯详细说明数值型、字符串型、数组或链表三种参数类型⽤例设计。
  2.1.1  数值型
  数值型的参数主要考虑以下⼏个⽅⾯设计：
  如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可
能会遍历取值范围内的各个值。  例如检查权限的接⼝：TaskChecker.checkTask(int taskID) taskID的取值范围是1-35，那么设计时考虑：
  ●1-35范围内和范围外的值；
  ●1-35的边界：0，1,35,36；
  ●类型的特殊值：-1,0
  ●数据类型的边界值：int的最⼩值最⼤值；
  ●因为1-35代码的权限ID不同，可能需要遍历1-35的每个值。
  常见问题和风险：
  ●特殊值处理不当导致程序异常退出；
  ●类型边界溢出
  ●取值范围外值未返回正确的错误信息等
  2.1.2  字符串型
  字符串型的参数，主要考虑字符串的长度和内容：
  例如接⼝转换设置闹钟的接⼝DayOfDDHH(String ddhh)，⽤例可以考虑：
  ●长度为4位，⽐4位少，⽐4位多；
  ●边界值：String的最⼤长度；
  ●特殊值：空字符；
  ●字符串内容可考虑类型：数字，⾮数字；
  ●特殊字符。
  ●如果是输⼊⽤户输⼊且其他⽤户可见的内容，则还需要考虑敏感字是否被正常过滤。
  可能出现的问题和风险：
  ●传⼊⾮特定类型程序异常退出
  ●超长字符未进⾏处理，导致存储、显⽰等异常
  ●其他⽤户可见设置的敏感字
  2.1.3  数组或链表类型
  参数类型为数组或链表时，⽤例可以考虑：
  例如批量提交任务的接⼝submitTask(int[] taskID)，参数⽤例设计考虑：
  ●正常取值：1-5个权限，范围外：6个权限；
  ●边界值：1-35的边界值，请求允许最⼤最⼩值；
  ●特殊值：0个；
  ●合法ID和不合法的；
  ●重复的ID等。
  可能存在的问题和风险：
  ●0个item时程序异常退出；
  ●重复的item处理时未去重导致结果异常等。
  2.2  针对逻辑设计
  接⼝需要进⾏⼀些逻辑处理的，那么按逻辑设计⽤例可以从以下⼏个⾓度分析。
  2.2.1  约束条件分析
  （1）数值限制：分数限制、⾦币限制、等级限制等等。
  例如：兑换Q币活动要求积分>50才可参与。
  （2）状态限制：登录状态等。
  例如：同步⽤户信息需要先登录账号。
  （3）关系限制：绑定的关系，好友关系等。
  例如：帮家⼈防骗功能只能查询绑定家⼈的来电信息。
  （4）权限限制：管理员等。
  约束条件的测试在中经常遇到，在接⼝测试中更为重要。它的意义在于：⽤户进⾏操作时，在该操作的前端可以已经进⾏了约束条件的限制，故⽤户⽆法直接触发请求该接⼝。但是实际上，如果有其他⼿段：例如UI有bug或者通过⼿段直接调⽤接⼝，那么接⼝是否针对这些条件进⾏了限制就尤为重要。
  例如常见的例⼦：要兑换5Q币需要200积分，但是我积分不⾜，所以兑换按钮是灰⾊⽆法点击的状态：
  正常⽤户是⽆法操作的，但是兑换其实是调后台的⼀个接⼝，如果绕过页⾯按钮的限制，直接调⽤后台接⼝兑换呢？是否可以兑换？预期当然是不能兑换的。因此积分这个数值限制就需要针对接⼝进⾏测试，并且⾮常重要。
  其他约束条件类似：
  ●时间约束：22：00之前；
  ●数值约束：积分200；限量5个；
  ●状态约束：登录管家；
  ●等等约束条件类似。
  常见的问题和风险：
  约束条件判断不⾜，导致⽤户可通过特殊⼿段获取利益
  2.2.2  操作对象分析
  操作通常是针对对象的，例如⽤户绑定号码，电话号码就是操作对象，⽽这个电话号码的话费、流量也是对象。
  对象分析主要是针对合法和不合法对象进⾏操作。例如下述⽤例⼦:
  ●⽤户A查询电话P1话费：
  ●⽤户A查询电话P1流量；
  ●⽤户A查询电话P2话费；
  ●⽤户A查询电话P2流量。
  后台的逻辑处理，如果⼀个电话已经被绑定过，从后台的⾓度是可以查询到该电话的话费和流量的。但是在⽤户侧，应该是A绑定了的电话，才能让A查询到该电话的话费。故类似对象的测试也必不可少。
  常见的问题和风险：
  ●⽤户可访问⾮权限内的其他⽤户信息、敏感信息，从⽽利⽤这些信息谋取利益。
  2.2.3 状态转换分析
  被测逻辑可以抽象成状态机，各个状态之间根据功能逻辑从⼀个状态切换到另⼀个状态。如果我们打乱了这个次序，从⼀个状态切换到另⼀个不在它下⼀状态集中的状态，那么逻辑将会打乱，就会出现逻辑问题。
  如上图所⽰，从某状态改变到新的状态，依赖于转换接⼝。⽽对于某转换接⼝，其输⼊状态是确定的，⽐如Fun23, 这个函数只能把状态2转换为状态3，⽽不能把状态1转换为状态3。那么测试点就可以是：
  （1）状态为状态2，调⽤接⼝Fun23（），状态切换到状态23；
  （2）状态为1,3等，调⽤接⼝Fun23（），状态不能切换。
  例如在做任务的时候，任务有三种状态：未领取，已领取未提交，已完成三种状态。
  那么可以这样设计：
  （1）正常的状态切换：未领取状态，领取任务后变为已领取状态；已领取满⾜任务条件提交后，变成已完成状态；完成后可以再次领取任务。
  （2）⾮正常的状态切换：未领取任务满⾜任务条件直接提交任务；已领取时再次领取任务等等。
  常见的问题和风险：
  可通过特殊⼿段达到原本不能的状态，从⽽谋取利益。
  2.2.4  时序分析
  在⼀些复杂的活动中，⼀个活动是由⼀系列动作按照指定顺序进⾏的，这些动作形成⼀个动作流，只有按照这个顺序依次执⾏，才能得到预期结果。
  在正常的流程⾥，这些动作是根据程序调⽤依次进⾏的，并不会打乱，在接⼝测试时，需要考虑如果不安装时序执⾏，是否会出现问题。
  例如，客户端数据同步是由客户端触发进⾏的，期间的同步⽤户⽆法⼲预。功能测试的时候可见的就是是否能正常进⾏同步，⽽进⼀步分析，同步流程实际涉及了⼀组动作：
  从时序图可以看出，后台有3个接⼝：登陆获取⽤户ID，上报本地数据，上报本地冲突。三个接⼝需要依次调⽤执⾏，才能完成同步。那么在接⼝测试就可以考虑打乱上述接⼝的执⾏顺序去执⾏，会有怎样的结果，是否会出现异常。例如：获取⽤户ID后不上报本地数据⽽直接上报本地冲突。
  ●常见的问题和风险：
  ●⾮顺序执⾏后，数据出现异常，可能还会出现程序其他异常
  通过打乱顺序获取利益
  2.3  针对输出设计
  针对输出设计其实是针对接⼝返回的结果进⾏分析。
  2.3.1  针对输出结果
  接⼝处理正确的结果可能只有⼀个，但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种，就可以针对不同结果设计⽤例。例如提交积分任务的时候我们通常能想到的是返回正确和错误，错误可能想到：⽆效任务，⽆效登录态，但是不⼀定能否完全覆盖所
有错误码，⽽接⼝返回定义的返回码可以设计更多⽤例：
  覆盖返回码也是⽤例设计的⼀种思路。
  常见问题和风险：
  （1）错误前端处理不⾜，导致前端异常；
  （2）错误提⽰处理不当，导致⽤户看到晦涩的错误码；
  （3）错误提⽰不当，导致⽤户不知道哪⾥出了问题，如何解决。
  2.3.2  接⼝超时
  接⼝正常情况下是有返回的，那么如果接⼝不返回呢？也就是说接⼝超时后的处理也是测试需要考虑的部分。如果超时处理不当，可能会引起以下问题：
  （1）未进⾏超时处理，导致整个流程阻塞字符串长度不同怎样取
  （2）超时后⼜收到接⼝返回，导致逻辑出现错乱
  2.4  其他测试设计
  2.4.1  已废弃接⼝测试
  已废弃协议，是指之前有定义，但是因为需求变更或其他原因，⽬前版本不⽤。这些接⼝虽然不再使⽤，但有可能代码并没有及时删除。如果利⽤技术⼿段调⽤这些接⼝，可能获取额外利益。
  例如，任务之前有个清理任务，在⼀个版本需求⾥将清理任务替换为下载任务。在新版本客户端已不再调⽤完成清理任务的接⼝；但是如果该接⼝未关闭，⽤户就可以继续请求submitTask(int taskID)接⼝完成清理任务获得积分。
  因此新版本在考虑兼容旧版本的同时，还应做好相关废弃接⼝的检查，避免⽤户获得额外利益。
  2.4.2  接⼝设计合理性分析
  接⼝定义是否合理可以从以下⼏个⽅⾯分析：
  （1）接⼝字段是否冗余；
  （2）接⼝是否冗余；
  （3）接⼝是否返回了调⽤⽅期望得到的信息；
  （4）接⼝定义是否可满⾜所有调⽤需求；
  （5）接⼝定义调⽤是否⽅便。
  2.5  ⼀个完整的例⼦
  下⾯举⼀个完整例⼦，通过上述⽅法来分析如何对接⼝进⾏⽤例设计。
  某模块提供了⼀个接⼝给其他模块，⽤户请求任务，接⼝定义如下：
  2.5.1  针对输⼊设计
  dialogDetailText（dialogButtonText类似）
  长度
  1）正常：请安装提⽰进⾏操作；
  2）边界：⼀个字：请；长度⾮常长：⽆悬浮窗权限，可能影响XX功能⽆法使⽤，请开始悬浮窗权限，以便获得更好的⽤户体验；甚⾄更长；
  3）特殊：空字符串。
  内容
  1）特定类型：中⽂，英⽂，数字等；
  2）特殊字符：/n/r/t ,.><?*$&^%~"??℡?€?等；
  3）敏感字符：⾮⽤户设置，不涉及。
  taskID（requestType类似）
  等价类
  取值范围内：1,5,10等；
  取值范围外：0，99。
  边界法
  取值范围边界：0,1,38,39,40
  数据类型边界：-2147483648 ,2147483648
  特殊值：0,-1等。
  遍历法：1,2,3,4,5…38,39对应每种不同ID。
  2.5.2  针对逻辑设计
  （1）约束条件分析
  去引导某功能需要：未完成过任务，任务有任务数据。
  那么⽤例可以是：以下情况下调requestTask：
  1）未使⽤过有任务数据时；
  2）未使⽤⽆任务数据时；
  3）使⽤过有任务数据时；
  4）使⽤过⽆任务数据时。
  如果有其他约束条件类似设计。
  （2）操作对象分析
  调⽤请求接⼝后，会显根据任务数据，引导对应的任务。任务数据，任务操作⽅式，任务功能都可以是对象。
  1）任务数据
  数据类型：本地，云端等
  数据有效性：正确数据，错误数据
  2）操作⽅式
  ⽅式：安装，下载，打开等等。
  3）任务功能
  功能：⽤户操作了该功能，未正常操作该功能；什么都不操作；完成⼀个任务功能；完成多个任务功能；任务功能使⽤顺序等等。
  对象：还需要关注，会不会操作到不合法的对象，例如任务数据和功能不对应等问题。
  （3）状态转换分析
  功能是有4个状态的：完成，未完成，未知。状态图如下：这⾥是产品⾥涉及的状态转换：
  针对该状态：
  1）正常状态转换：未完成状态请求并完成任务后是否可变成完成状态；未完成状态请求但不完成，还是未完成状态。
  2）⾛不到的状态路径：未知和完成状态请求任务，不能进⾏进⾏该任务。
  2.4  时序分析
  从时序的⾓度分析，调⽤请求接⼝前需要以下2步动作：
  1）拉取任务数据；
  2）判断任务状态。
  从时序得到的⽤例有：
  正常时序：按照正常时序请求1 2 3；
  缺失的时序
  缺少动作1调2 3；缺少动作2调1 3；缺少动作1和2直接调。
  打乱的时序
  打乱的时序：2 1 3，还可以有1 3 2，2 3 1，3 1 2，3 2 1。
  针对处理逻辑的设计中，可能使⽤某⼀种或某⼏种⽅式就可以将⽤例覆盖前，故实际使⽤中，可能不会全部使⽤，只要到最合适的⽅式覆盖⽤例即可。
  2.5.3  针对输出分析
  请求任务接⼝返回的数据是任务完成结果，即返回完成，未完成两种状态（未知都作为完成返回）。
  从结果可以考虑遍历：
  1）未完成
  2）完成
  3）完成-未知
  从接⼝处理时间分析，考虑：请求后快速返回，很长时间才返回，甚⾄不返回结果的情况。
  3  ⼩结
  接⼝⽤例设计⽅法中，针对输⼊、输出的设计是通⽤的，接⼝设计时都可⽤到。对于接⼝逻辑的设计可能会应⽤⽐较适合的⼀种或⼏种⽅法，在接⼝⽤例设计时，需要选取最合适的⽅法去覆盖被测逻辑。
转⾃：

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