怎么设计接口测试用例？
回答·19
最热
最新
- 接口测试属于功能测试，接口测试的流程类似于以往的功能测试。 设计接口用例时，主要从四个方面：功能，业务逻辑，异常，安全。 1.功能：是否正常：是否按照接口文档实现； 2.业务：判断业务逻辑：是否依赖业务； 3.异常：参数异常和数据异常； 4.安全测试用例设计：cookie，header，唯一识别码等。
- 1、接口测试 接口：主要是子模块或者子系统间交互并相互作用的部分。 这里说的接口是广义的，客户端与后台服务间的协议；插件间通信的接口；模块间的接口；再小到一个类提供的方法；都可以理解为接口。因此，可以分析，系统间的接口包含三部分：输入、处理逻辑、输出。 接口测试：是指针对模块或系统间接口进行的测试。 2、应该怎么分析一个接口？ 获取接口文档：和黑盒测试一样，我们是从需求文档中去挖掘测试点，设计测试用例。对于接口测试，同样是有对应的接口文档的。 分析接口文档，提取测试点： 1）输入： 接受哪些参数、参数的类型、可选参数和必选参数等；根据输入参数采用等价类、边界值分析法等进行设计； 2）业务逻辑：对于一个接口，不同的输入参数或组合，流程或状态的转移是不同，可以根据业务逻辑画出流程图或状态转移图，确保每种状态至少被访问了一次； 3）输出：根据文档规定的输出，反向设计测试数据，使所有的输出状态都被包含了； 测试用例：同时对输入、业务逻辑、输出进行考虑时，肯定会存在用例的冗余，在最大限度覆盖业务功能和规则下，选取最优用例集合。同时，需要考虑异常数据和场景。 3、怎么确定用例的覆盖率？ 在没有特殊要求的情况下，至少需要考虑以下内容： 1）业务功能覆盖是否完整 2）业务规则覆盖是否完整 3）参数验证是否达到要求（边界、业务规则） 4）接口异常场景覆盖是否完整 如果接口需求还包含性能或者安全要求，还要对接口进行性能测试和安全测试，就需要考虑：性能指标是否满足要求、安全指标是否满足要求。 4、接口测试发现的典型问题 接口测试经常遇到的 bug 和问题，如下： （1）传入参数处理不当，导致程序 crash； （2）类型溢出，导致数据读出和写入不一致； （3）因对象权限未进行校验，可以访问其他用户敏感信息； （4）状态处理不当，导致逻辑出现错乱； （5）逻辑校验不完善，可利用漏洞获取非正当利益等。
- 1.参数校验 2.流程设计 3.集成设计
- 接口测试也可以说是功能测试，所以说接口测试用例可以从功能测试用例里面摘出来一部分直接用作接口测试用例，当然这也不是全面的，就需要你根据项目场景自行设计
- 我的用例设计考虑 4 点 1.功能是否实现 2.逻辑 业务 3.异常场景 4.安全性
- 设计接口测试用例这个问题你问的很有意思，既然是接口，那么它是有一个定义的标准的输入规则，标准的输出规则，其内部的里逻辑是黑盒状态，那么你就可以把他想象成她是已知输入也已知输出的一个东西，以此去设计你的测试用例就可以了，常用的方式是接口的测试用力，要采用极限测试能力或者叫极端测试，简单理解就是传入的数据要进行两个极端的数据操作，如果两个极端问题不大，那么，其极端中间范围内部分就会不会有什么太大问题。
- 必选参数和可选参数。 参数的有效值无效值 边界值测试。
- 功能测试用例设计方法大家都会，所谓接口测试用例设计其实和功能用例差不多，核心方法和思想都是一致的。 由于接口参数不好理解，也看不到摸不着，我们可能会望而生畏。其实有一个方法可以直接将接口用例设计转变成功能用例设计。我们可以把接口的每个参数都当成一个输入框来对待，此时设计用例就会好理解很多 按照优先级，业务用例优先级最高，其次才是参数的缺失、长短、类型 ● 正常业务 1.覆盖所有参数的正常数据 2.覆盖必填参数的正常数据 3.组合所有参数中的有效数据 什么样的情况下才需要去组合参数呢？ 以 创建交易接口为例： client: 有效数据为PC、NATIVE、REACT、MINI、WAP way: 有效数据为BUY_NOW、CART 组合后5*2=10条用例 ● 权限校验 1.登录权限 2.数据权限：你不能操作他人数据 ● 异常业务 对于接口来说，每个参数都有它特定的意义。很可能你的某一个参数就代表了某一种业务数据 比如立即购买接口的参数： sku_id: 商品数据，数据的异常状态有下架、删除 num: 购买数量，对应的其实库存，异常状态是不能超过库存 activity_id: 促销活动数据，数据的异常状态，促销活动未开始、促销已结束 ● 参数异常 参数必填校验、参数缺失、参数为null、参数数据范围、参数长度、参数包含特殊字符
- 功能，业务逻辑，异常，安全
- 这个问题很刁钻，没接口文档吗，看着使劲测