接口测试用例的设计原则（接口测试用例的编写要点）

本篇文章给大家谈谈接口测试用例的设计原则，以及接口测试用例的编写要点对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享接口测试用例的设计原则的知识，其中也会对接口测试用例的编写要点进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、如何简单设计接口测试用例
• 2、设计测试用例需要遵循哪些原则
• 3、测试用例设计的基本原则
• 4、接口自动化测试测试用例设计
• 5、接口测试用例怎么设计
• 6、测试用例设计的基本原则是什么

如何简单设计接口测试用例

接口测试是项目测试的一部分
，它测试的主要对象是接口
，是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与所测系统之间以及内部各系统之间的交互点。测试的重点是检查数据交互、传递、和控制管理过程以及系统间的相互依赖关系等。
如何设计接口测试用例?首先，明确出发点，和所有的测试一样
，接口测试出发点是你要证明所测的程序是错误的。以这个出发点为导向
，你的设计行为就会尽量朝这个方向，更易发现问题
其次，选择好测试对象。对于一个系统做接口测试选择好的测试对象是接口测试关键。一个系统有无数的接口
，每个接口如果分别测试
，那将是很痛苦的一件事情，而且任何一个内部接口的变动
，都将导致我们用例的不可用。
可将这些最外层的接口分为两类:一类是数据进入系统的接口;一类是数据流出系统的接口。进入系统的接口实际是我们用例的执行调用的接口。可通过变化参数对这些接口进行调用
，模拟外部的使用;而流出的接口则是我们用例真正该验证的点。数据从哪里流出，流出时的状态如何
，此时系统又是什么状态都是我们所应该验证的。
然后，确认完整的测试对象的功能:确认外部接口提供给使用这些接口的外部用户什么样的功能，外部用户真正需要什么样的功能。此两个功能一定要准确详细，用例的设计要严格按照测试对象功能设计才是正确的用例。
最后当出发点、对象、功能都确定了，就可以真正设计用例了。下面详细介绍下如何去设计一个结构好、可读性高、渗透性强的接口测试用例。
接口测试用例设计和测试用例设计一样，用例设计的内容应该包括:主要测试功能点、测试环境、测试数据、执行操作以及预期结果。
1)接口测试环境分为两种:一种是程序内部的环境;一种是程序的所调用外部接口的环境。
2)接口测试测试数据分为接口参数数据和用例执行所需系统数据。数据的设计、准备测试用例的数据上需要花费更多的心思。要通过好的测试数据使用例查找问题。接口参数数据需对每个参数根据测试接口的实际的功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列
，不要遗漏了某些边界值和错误点的数据。每个用例执行所需系统数据和接口参数数据尽可能的采用不一样的数据
，使用例更容易发现问题。
3)测试功能点，如果一个接口功能复杂时推荐对接口用例进行结构划分
，这样子用例具有更好的可读性和维护性。接口划分原则为以接口提供的功能点的不同进行合适粒度的划分。同一功能点的用例又可根据测试环境的不同、数据的不同进行用例的填充。
4)接口测试用例执行操作非常简单，就是所测接口的调用。
5)预期结果验证，这也是接口用例设计的很关键的一步
，应该细而不冗余。每个用例均需验证
，避免一个用例中重复做相同的验证
，提高测试用例的效率。
如何设计接口测试用例小例子:
简单划分可以按照2个基本组成要素进行划分:1.
参数
2.
业务
以下为最简单的一种划分用例的方法，可能涵盖不全，但只为说明一种划分接口用例的方法方式以及需要考虑的测试用例的测试点
为何要如此设计，是为了更好的将用例分类为程序规定型以及业务限制型，尽量的保证覆盖，尽量细化到点的划分形式来保证工作时间的预估和计划。
所有的自动化接口的测试用例
都基本围绕三部曲进行，传数据，执行，校验返回的数据和期望数据是否一致来构成每个简单的测试用例。
有清晰的线路和清晰的思维，才能做好整体测试的掌控。

设计测试用例需要遵循哪些原则

设计测试用例需要遵循接口测试用例的设计原则的原则有接口测试用例的设计原则：

1、单个用例覆盖最小化原则。

2、测试用例替代产品文档功能原则。

3、单次投入成本和多次投入成本原则。

4、使测试结果分析和调试最简单化原则。

扩展资料接口测试用例的设计原则：

1、测试用例接口测试用例的设计原则的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等。

2、测试结果的可判定性：即测试执行结果的正确性是可判定的接口测试用例的设计原则，每一个测试用例都应有相应的期望结果。

3、测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

测试用例设计的基本原则

大家好，我是十一。

前面我们用了7篇介绍了5种测试用例设计方法，分别是 等价类划分法 、 边界值分析法 、 因果图法 、 判定表法 、 正交实验法 。5种方法各有利弊，根据我多年测试经验，综合使用多种设计方法比使用一种设计方法更有效，设计出来的测试用例覆盖率更高。另外，我们在设计测试用例的时候需要根据任务说明、需求说明、选定的测试策略以及自身因素来综合考虑具体选择哪些设计方法对当前的测试工作更有效！

接下来我为大家分享一个我认为合理有效的策略，该策略原型来源于梅尔斯的《软件测试的艺术》，根据我的经验做了稍微改变以及说明，供大家参考：

1.如果规格说明中包含输入条件组合的情况。

    a.如果输入条件较少，应优先考虑因果图分析法；

    b.如果输入条件较多，测试用例量过大，则应优先考虑正交实验法。

2.在任何情况下都应使用边界值分析方法。

边界值分析可以产生一系列补充的测试条件。事实上，我们在实际工作中边界值分析法是一个必不可少的重要的设计方法。但是缺点也显而易见，他不能担起测试用例设计的重任，必须与其他设计方法结合使用。

3.应为输入和输出确定有效和无效等价类。

    a.等价类划分法可以同边界值分析法一样与其他测试用例结合使用，在必要情况下对上面确认的测试用例进行补充

    b.另外，为其他设计方法提供技术支持，比如：在正交表构建过程中，我们确定因素水平就会用到等价类划分法和边界值分析法。

4.使用错误推测法补充更多的测试用例。

这个方法主要是根据规范、经验、常识等提取/增补测试用例。

5.针对上述测试用例集检查程序的逻辑结果。

此处会用到白盒测试用例设计方法，比如：判定覆盖、条件覆盖、判定/条件覆盖或者多重条件覆盖准则。（这些设计方法我们往后放放，暂时先忽略这部分）

要注意的是：使用上述策略并不可能发现所有的错误，但实践证明，这是一个有效的且合理的方案。

另外，关于测试用例还有一些点需要大家注意。

1.一个测试用例必须包含前置条件（背景）、测试输入、测试输出（期望结果）；

2.测试用例的粒度越小越好；粒度小的测试用例具有如下优点：

    a测试用例的覆盖边界定义更清晰

    b.测试结果对产品问题的指向性更强

    c.测试用例间的耦合度最低，彼此之间的干扰也就最低

    d.测试用例可读性比较高，信息含量越小，可读性越高

3.测试用例必须描述简洁清晰；

    a.测试用例必须描述清晰。因为测试用例并不是给自己用的，而且测试用例大多数不是一次性的，所以我们必须要描述清晰，保证下次可用，他人可用。

    b.测试用例必须简洁。通常，我们的工作周期都是有限的，且现在迭代更新速度越来越快，所以我们在编写测试用例的时候要注意在描述清晰的前提下，使用简洁的语言。

4.测试用例必须要持续更新；

    a.需求大多数情况不是永恒不变的，所以我们在需求发生了改变的时候或者在测试时候发现测试用例描述不准确，不完全时就要及时修改测试用例，以保障测试用例的准确性；

    b.测试用例都是人工设计出来的，设计者可能对需求的理解或者功能知识点的理解存在偏差，这样就会造成设计出来的测试用例不准确甚至不正确，这时候我们就需要有辨别是非的能力，且发现测试用例错误后要及时修订，以免造成二度损失/二度浪费。

5.测试用例集合必须是一个“完备”的集合，保证需求中的每个功能点都被覆盖到；这里要注意的是，测试用例要覆盖所有的功能点，而不是要做完全测试；

    a. 完全测试： 对产品进行穷尽测试，把所有可能以及所有可能的组合均测试一遍

    b. 覆盖所有的功能点： 要求覆盖需求中所有显性功能点（需求说明书提到的）、隐性功能点（没有提到，但是是约定俗成的或者常识性的点，比如我们在测试身份证号码的文本框时候，需求说明书可能只会写：合法允许保存，不合法文本框后提示非法用户，此处不会给出身份证号码具体什么是合法，什么是非法；那么这个点就是隐性功能点；再比如：密码框必须是密文，很多需求中也不会强调，但是我们在测试时候一定要设计这个点的测试用例），我们可以对所有数据通过等价类划分和边界值分析法提取出有代表性数据来做测试即可。

6.只有在深入理解软件需求、甚至架构设计后，我们才有可能设计出“完备”的测试用例集 ；因此，我们在设计测试用例之前一定要好好研究软件需求（对于初级测试人员来讲,大家只要做好这点即可）、架构设计、实际设计等。

7.先正常再异常，且一定要对异常进行测试。 这个很重要，很多人不是忽略了异常情况，就是次序混乱，导致测试用例遗漏或者重复。

8.最最重要的一点，我们在测试用例设计之前一定要先对需求进行测试！ 这个就是在需求分析、需求评审阶段测试一定要参与进去，测试参与到项目的时间越早越好。

好了，今天到此结束。如有任何问题请留言及时与我沟通，我会尽快回复大家！谢谢大家~我们下次再见！

接口自动化测试测试用例设计

浅谈接口自动化测试测试用例设计

一、   前言   

很多中台项目接口测试用例的设计原则，大部分为接口测试。为接口测试用例的设计原则了使新入职接口测试用例的设计原则的测试同事尽快融入项目，以及迭代开发中方便管理测试用例。完成该总结。

二、   测试用例设计思路   

1、 接口类型概述及优先级  

1） 提供给第三方调用的接口  

2） 内部系统使用，核心功能接口  

3） 内部系统使用，非核心功能接口  

基本按照1）2）3）的顺序进行测试，特别情况除外

2、 单接口测试优先级  

1） 优先测试正向测试用例，保证基本功能实现  

2） 设计逆向测试用例，确保接口的健壮性  

3） 满足前提条件的测试用例  

4） 默认参数是否满足  

5） 参数校验  

6） 参数间联动关系

7）多参数错误处理的优先顺序校验

三、   设计分析   

1、 满足前提条件的测试用例  

测试目标接口需要满足前置条件才能成功获取数据。

例如：需要登录token，通过传入参数获取下游接口数据

2、 携带默认参数的测试用例  

携带默认参数的测试用例仅需要设计一条，所有默认参数的字段都不填写，其他字段输入正常。

[if !supportLists]3、 [endif]参数校验  

参数校验包含如下几方面：

[if !supportLists]1）[endif]输入参数是否为必须输入项

[if !supportLists]2）[endif]输入参数的类型

[if !supportLists]3）[endif]输入参数的枚举值校验

[if !supportLists]4）[endif]输入参数长度校验

以上测试用例最好根据字段一一校验，排除互相干扰

[if !supportLists]4、 [endif]参数间联动  

有些参数见存在彼此制约的关系，根据实际情况设计测试用例

例如:A字段为1时，B字段一定为空。否则报错。

那么测试用例设计时应为：A字段为1时，B字段为空；A字段为1时，B字段不为空；A字段不为1时，B字段为空；A字段不为1时，B字段不为空；四条测试用例

这样基本覆盖所有分支流程。

[if !supportLists]四、 [endif] 测试用例实践操作

接口测试用例样例:

多条件查询接口

测试方法：使用robotFramework测试doubbo接口

协议请求方式：post

接口协议：JSON

消息请求列表

字段名数据类型默认值必须项备注

IDint 是长度为2

Tokenstring 是设备令牌

Statusstring 是1：正常

2：异常

typeint  Status为1时，为必须输入项

sizestring  默认值
消息返回列表

字段名数据类型必须项备注

Codeint是正常：20000

异常：20001

Messagestring是 

typeMessageint Status=1的所有ID

 

用例设计

 

NO. 测试内容 前置条件 输入参数 输出参数 用例属性

1目标数据为一条预置一条符合条件的数据Status=1，其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

正向测试用例

2目标数据为多条预置多条符合条件的数据Status=1，其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

正向测试用例

3 Token必须项检查 预置多条符合条件的数据Status=1，token输入为空，其他参数输入正常返回code=20001

typeMessage中返回为空

满足前提条件

4 Token正确性检查 预置多条符合条件的数据Status=1，token输入错误，其他参数输入正常返回code=20001

typeMessage中返回为空

满足前提条件

5 Status 必须项检查 预置多条符合条件的数据Status为空，其他参数输入正常返回code=20001

typeMessage中返回为空

参数校验

6 Status枚举预置多条符合条件的数据Status为1，其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

参数校验

7 Status枚举预置多条符合条件的数据Status为2，其他参数输入正常返回code=20000

typeMessage中返回的ID与预置数据一致

参数校验

8 Status枚举预置多条符合条件的数据Status为3，其他参数输入正常返回code=20001

typeMessage中返回null

参数校验

9 Status=1，时联动校验预置多条符合条件的数据Status为1，type为空；其他参数输入正常返回code=20001

typeMessage中返回null

联动校验

10 Status接口测试用例的设计原则！=1，时联动校验预置多条符合条件的数据Status接口测试用例的设计原则！=1，type为空；其他参数输入正常返回code=20000

typeMessage中返回对应ID

联动校验

11 Status！=1，时联动校验预置多条符合条件的数据Status！=1，type不为空；其他参数输入正常返回code=20000

typeMessage中返回对应ID

联动校验

12 Size默认值输入校验预置多条符合条件的数据Size输入为空，其他参数输入正常返回code=20000

typeMessage中返回对应ID

默认值校验

13 Size默认值输入校验预置多条符合条件的数据Size输入不为空，其他参数输入正常返回code=20000

typeMessage中返回对应ID

默认值校验

14 ID 必须项检查 预置多条符合条件的数据ID为空，其他参数输入正常返回code=20001

typeMessage中返回为空

参数校验

15 ID 长度检查 预置多条符合条件的数据ID长度大于2，其他参数输入正常返回code=20001

typeMessage中返回为空

参数校验

16 破坏性测试预置多条符合条件的数据输入的参数类型错误请求未接收，返回404 稳定性测试

17 破坏性测试预置多条符合条件的数据输入的参数与提供的参数名称不一致请求未接收，返回404 稳定性测试

18 破坏性测试预置多条符合条件的数据输入的参数与提供的参数数量不一致请求未接收，返回404 稳定性测试

19 破坏性测试预置多条符合条件的数据输入的参数与提供的参数格式不一致请求未接收，返回404 稳定性测试

 

总结：自动化测试过程中会有一条自动化测试用例覆盖多种情况的可能（例如：正向测试用例与联动性验证的 Status=1，type输入不为空的测试用例重复，所以选择一条用例验证 。 ），以上的测试用例满足自动化的要求，手动测试过程中需要增加部分验证性的测试用例。且由于使用的测试工具特殊性，无需检查输入参数的类型。

接口测试用例怎么设计

在开始接口测试之前，我们想一下，接口测试的流程是什么？说到这里，有些人就会产生好奇和疑问，心里mmp：接口测试要什么流程哈？？？不就是参考接口文档，直接利用接口测试工具（例如jmeter和postman）测试。。。其实，如果一个project中，只是几个接口，你完全可以做临时的接口测试，但project可不止几个接口，少则几十条接口，多则成百上千接口。另外，如果你公司的这个项目，第一次做接口测试。而且古人说过：“无规矩不成方圆。”所以哈，我们还是有必要严格遵守接口测试的流程。
二、接口测试的流程
接口测试属于功能测试，接口测试的流程类似于以往的功能测试。接口测试的流程如下：
测试尽早找开发拿接口文档（需求文档）；
根据接口文档编写测试用例（用例编写可按照以往规则写，比如等价类划分，边界值，场景法等设计方法）；
执行测试，查看不同的参数请求，接口返回的数据是否达到预期

三、为什么要写用例
理清思路，避免漏测和重复测；
提高测试效率；
跟进测试进度；
更好的发现问题，记录问题，复现问题；
跟进重复性工作；
告诉领导：我做过；
接口测试流程中的一个产物（测试用例）
上面7点，有用例，自己心中有数，不用一个测试点重复测好多次，也避免漏测。

测试用例设计的基本原则是什么

测试用例设计的最基本要求：覆盖住所要测试的功能。这是再基本不过的要求了，但别看只是简单的一句话，要能够达到切实覆盖全面，需要对被测试产品功能的全面了解、明确测试范围（特别是要明确哪些是不需要测试的）、具备基本的测试技术（如：等价类划分等）等。那么满足了上述这条要求是不是设计出来的测试用例就是好的测试用例了呢？答案：在理论上是，但在实际工程中还远远不是。之所以理论和实际会有这样的差别，是因为在理论上不要考虑的东东，而在实际工程中是不得不考虑的

-

成本。这里的成本包括：测试计划成本、测试执行成本、自动化测试用例、测试自动化成本，测试分析成本，以及测试实现技术局限、测试环境的bug、人为因素和不可预测的随机因素等引入的附加成本等。

此文出自:中国it实验室 关于接口测试用例的设计原则和接口测试用例的编写要点的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 接口测试用例的设计原则的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口测试用例的编写要点、接口测试用例的设计原则的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。