后台接口测试ui设计包括哪些内容？什么情况下开展接口测试？

很多人可能不知道，其实ui设计是比较复杂的，需要后台接口多次进行测试。那后台接口测试ui设计包括哪些内容呢?还有，什么情况下开展接口测试?下面就一起跟小编来了解一下相关的内容吧。

　　后台接口测试ui设计包括哪些内容

　　针对输入设计

　　(1)数值型：如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可能会遍历取值范围内的各个值。

　　例如检查权限的接口：TaskChecker.checkTask(int taskID) taskID的取值范围是1-35，那么设计时考虑：

　　●1-35范围内和范围外的值;

　　●1-35的边界：0，1,35,36;

　　●类型的特殊值：-1,0

　　●数据类型的边界值：int的最小值最大值;

　　●因为1-35代码的权限ID不同，可能需要遍历1-35的每个值。

　　常见问题和风险：

　　●特殊值处理不当导致程序异常退出;

　　●类型边界溢出

　　●取值范围外未返回正确的错误信息等

后台接口测试ui设计

　　(2)字符串型：字符串型的参数，主要考虑字符串的长度和内容

　　例如接口转换设置闹钟的接口DateUtil.getDayOfDDHH(String ddhh)，用例可以考虑：

　　●长度为4位，比4位少，比4位多;

　　●边界值：String的最大长度;

　　●特殊值：空字符;

　　●字符串内容可考虑类型：数字，非数字;

　　●特殊字符。

　　●如果是输入用户输入且其他用户可见的内容，则还需要考虑敏感字是否被正常过滤。

　　可能出现的问题和风险：

　　●传入非特定类型程序异常退出

　　●超长字符未进行处理，导致存储、显示等异常

　　●其他用户可见设置的敏感字

　　(3)数组或链表类型

　　例如批量提交任务的接口submitTask(int[] taskID)，参数用例设计考虑：

　　●正常取值：1-5个权限，范围外：6个权限;

　　●边界值：1-35的边界值，请求允许最大最小值;

　　●特殊值：0个;

　　●合法ID和不合法的;

　　●重复的ID等。

　　可能存在的问题和风险：

　　●0个item时程序异常退出;

　　●重复的item处理时未去重导致结果异常等。

　　针对ui逻辑设计

　　(1)约束条件分析

　　意义在于：用户进行操作时，在该操作的前端可以已经进行了约束条件的限制，故用户无法直接触发请求该接口。但是实际上，如果有其他手段：例如UI有bug或者通过技术手段直接调用接口，那么接口是否针对这些条件进行了限制就尤为重要。

　　例如常见的例子：要兑换5Q币需要200积分，但是我积分不足，所以兑换按钮是灰色无法点击的状态，正常用户是无法操作的，但是兑换其实是调后台的一个接口，如果绕过页面按钮的限制，直接调用后台接口兑换呢?是否可以兑换?预期当然是不能兑换的。因此积分这个数值限制就需要针对接口进行测试，并且非常重要。

　　常见的问题和风险：约束条件判断不足，导致用户可通过特殊手段获取利益

　　(2)操作对象分析：对象分析主要是针对合法和不合法对象进行操作。A用户不能查看到B用户的用户信息。

　　(3)状态转换分析

　　被测逻辑可以抽象成状态机，各个状态之间根据功能逻辑从一个状态切换到另一个状态。如果我们打乱了这个次序，从一个状态切换到另一个不在它下一状态集中的状态，那么逻辑将会打乱，就会出现逻辑问题。

　　(4)时序分析

　　在一些复杂的活动中，一个活动是由一系列动作按照指定顺序进行的，这些动作形成一个动作流，只有按照这个顺序依次执行，才能得到预期结果。

　　在正常的流程里，这些动作是根据程序调用依次进行的，并不会打乱，在接口测试时，需要考虑如果不安装时序执行，是否会出现问题。

　　常见的问题和风险：非顺序执行后，数据出现异常，可能还会出现程序其他异常通过打乱顺序获取利益

　　针对输出设计

　　(1)针对输出结果

　　接口处理正确的结果可能只有一个，但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种，就可以针对不同结果设计用例。

　　常见问题和风险：

　　(1)错误前端处理不足，导致前端异常;

　　(2)错误提示处理不当，导致用户看到晦涩的错误码;

　　(3)错误提示不当，导致用户不知道哪里出了问题，如何解决。

　　(2)接口超时

　　接口正常情况下是有返回的，那么如果接口不返回呢?也就是说接口超时后的处理也是测试

　　要考虑的部分。如果超时处理不当，可能会引起以下问题：

　　(1)未进行超时处理，导致整个流程阻塞

　　(2)超时后又收到接口返回，导致逻辑出现错乱

　　其他测试设计

　　(1)已废弃接口测试

　　已废弃协议，是指之前有定义，但是因为需求变更或其他原因，目前版本不用。这些接口虽

　　然不再使用，但有可能代码并没有及时删除。如果利用技术手段调用这些接口，可能获取额

　　外利益。

　　(2)接口设计合理性分析

　　接口定义是否合理可以从以下几个方面分析：

　　(1)接口字段是否冗余;

　　(2)接口是否冗余;

　　(3)接口是否返回了调用方期望得到的信息;

　　(4)接口定义是否可满足所有调用需求;

　　(5)接口定义调用是否方便。

后台接口测试ui设计

　　什么情况下开展接口测试？

　　1.项目处于开发阶段，前后端联调接口是否请求的通?(对应数据库增删改查)--开发自测

　　2.有接口需求文档，开发已完成联调(可以转测)，功能测试展开之前

　　3.专项测试：如测流量大小，查看图片压缩大小，测试接口请求响应时间

　　4.版本上线前，进行整体回归测试，查看接口是否有异常(如404等)。对准备上线的版本进行抓包，查看服务器地址是都正确

　　5.版本功能稳定后，接口自动化

　　6.还可以应用在安全测试，性能测试领域等。

　　以上这些是小编给大家介绍的后台接口测试ui设计包括哪些以及什么情况下开展接口测试的相关内容，ui设计比较复杂，涉及的内容比较多。想了解更多相关信息，可以继续留意我们的网站。