接口测试用例编写原则（接口测试用例编写原则有哪些）

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

本文目录一览：

• 1、接口测试流程是怎样的？
• 2、请问Jmeter进行接口功能测试操作步骤是怎样的？
• 3、接口测试的测试点有哪些
• 4、软件测试的分类&测试用例的设计&如何编写测试用例

接口测试流程是怎样的？

我们在做接口测试的时候需要根据流程进行，否则就达不到预期的效果，那下面我们就从测试前、测试中、测试后讲下接口测试的流程
①测试前
1.接口测试计划制定
2.接口测试用例和数据的准备
3.接口测试环境准备
4.编写接口测试脚本
5.测试前准备操作
6.测试脚本调试
7.接口测试内容制定
②测试中
1.接口测试的执行策略（包括执行轮次和顺序）
2.接口测试执行过程监控到失败后的重试
3.线上只读接口的测试
③测试后
1.测试后产生垃圾数据的清除
2.测试失败原因分析
3.接口测试bug的提交和回归验证
4.线上监控到紧急bug的验证
5.接口测试后复盘总结
我朋友当初在黑马程序员学习时候就直接整理文档给了我一份，这些也都有。

请问Jmeter进行接口功能测试操作步骤是怎样的？

操作步骤:
1、指定接口功能测试相关测试计划
2、从 API 文档提取接口清单
3、编写测试用例并设计测试数据
4、编写测试脚本并导入测试数据
5、执行脚本并逐条比对每条测试数据的实际结果与预期结果是否一致
各步骤主要实现:
1、指定接口功能测试相关测试计划
对程序不同模块进行任务划分，一般包括: 模块以及相关描述，指定该模块主要责任人，工期,预期产出以及当前进度等
2、从 API 文档提取接口清单
API 文档对各个接口实现具有完整且详细的流程说明，以及举例，但是对于我们测试而言，内容相对冗余，测试前期，一般会对API文档的各个接口，进行简化，压缩，提取接口测试时必须数据，以提高接口测试效率,其中简化压缩的结果就是接口清单
3、编写测试用例并设计测试数据
功能测试时，模拟用户的多样性操作设计测试数据是核心实现之一,该过程大致通过两步骤实现:
步骤1: 设计测试用例，该过程是抽象的非具体的实现，是要声明预期使用那些类型的测试数据，而不设计具体数据,设计测试用例时原则主要有如下几点:
a)、覆盖所有必选参数
b)、组合可选参数
c)、设计边界值数据
d)、设计超出范围的数据
e)、覆盖所有枚举值
f)、设计错误数据
g)、设计特殊符号数据
.....
另外，设计时需要在测试用例中声明该接口访问的 URL，请求方式以及预期结果等
步骤2: 根据测试用例声明的数据类型，设计具体的测试数据，此过程为具体非抽象的实现，最终设计的数据一般会被保存在csv文件中
4、编写测试脚本并导入测试数据
功能测试时，需要针对同一功能脚本提交多条不同的测试数据，此实现中，一般使用 CSV Data Set Config 来读取批量数据，动态的参数化的获取并设置测试数据，可以提高测试效率
5、执行脚本并逐条比对每条测试数据的实际结果与预期结果是否一致
步骤4批量操作完毕，要将提交的每条测试数据的执行结果与测试用例中对应的执行结果，相比对，如果预期与实际结果一致，一般无 BUG，不一致时，则可能有 BUG，当然对具体实现有疑议，可以写入备注
以上内容均来自传智播客论坛，还有相关配套视频课程。找不到就官网对话框领取。

接口测试的测试点有哪些

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

测试的策略：

接口测试也是属于功能测试接口测试用例编写原则，所以跟我们以往的功能测试流程并没有太大区别，测试流程依旧是：

评审测试接口文档（需求文档）

根据接口文档编写测试用例（用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法）

执行测试，查看不同的参数请求，接口的返回的数据是否达到预期

那么设计测试用例时我们主要考虑如下几个方面：

功能测试：

接口的功能是否正确实现了

接口是否按照设计文档中来实现（比如username参数写为了user，那么这就不符合，因为接口文档在整个开发中都需要使用，所以接口实际的设计要与接口设计文档中保持一致）

兼容性测试： 比如说今天接口进行了调整，但是前端没有进行变更，这时候需要验证新的接口是否满足旧的调用方式

错误码测试： 通用的错误码与业务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的覆盖所有的情况

返回值测试： 返回值除了内容需要是正确的，还需要类型也是正确的，保证调用方拿到这些参数能够正确的解析

参数边界值、等价类测试

json格式测试： 通常我们的接口一般设计的都是传递json串，那么就需要去测试 如果传递非json的情况，这时候程序会不会正确的处理，返回相应的 error code

默认值测试： 很多情况一些非必填的参数会有默认值，比如说一个查询的接口，参数count为返回查询的结果数量， 默认为10，那么就应该有一条case来测试，当然前置条件是数据库里面必须要存在这样的数据超过10条。

逻辑业务：

是否有依赖业务，比如查看订单，是需要用户首先登录的，所以肯定要保证登录了或有相应的cookie

业务逻辑测试： 传递正确的参数，接口对数据库进行查询的操作，需要去验证数据库查询是否正确，接口对数据库进行 增删改的操作，也需要看数据库是否同步进行了这些操作

异常测试：

异常分为两类，参数异常和数据异常

参数异常：

关键字参数：将参数写为开发语言中的关键字

参数为空：比如去掉了username参数

多或少参数：多或者少参数的验证，现在还不确定如果一个接口多了参数如果没有报错是否是合理的，或者是否需要优化，因为就目前开发给予的答案是，一般不对接口多了参数的处理

错误参数：比如将username参数写为了user等看是否能返回相应的error code

数据异常：

关键字数据：将参数的值填为开发语言中的关键字

数据为空：将参数的额值填为空

长度不一致：因为数据库中每个字段都设置有字段长度，填写不符合的长度进行验证

错误数据：就是将参数的值任意填写，或填写不存在的数值

异常类型测试： 比如count参数，这个参数的类型一定是可以转换为int类型的，这时候我们需要测试如果传的一些不可以 转换为int类型值来测试代码是否加入判断

性能测试：

响应时间

吞吐量

并发用户数

占用内存，CPU等

安全性测试：

敏感信息是否加密

必要参数是否后端也进行校验（现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证）

接口是否防恶意请求（SQL注入）

cookie：就是将header中的cookie修改或删除后看是否能返回相应的error code

header：就是删除或修改header中部分参数的值，看是否能返回相应的error code

唯一识别码：删除修改唯一识别码测试

软件测试的分类&测试用例的设计&如何编写测试用例

常见的开发模型：

V模型、瀑布模型、敏捷开发模型、W模型

软件生命周期：

1、问题的定义及规划

2、需求分析

3、软件设计（明确怎么做！）

4、软件编码

5、软件测试

6、运行维护

测试生命周期：

单元测试：一般是开发完成时

集成测试：单元测试之后，单元之间接口是否正确，数据是否正常传递。比如说注册和充值两个功能是否能够连通。

系统测试：根据测试用例，进行完整的系统测试

验收测试：用户对软件进行验收

软件测试阶段：

单元、集成、系统、验收（正式验收、Alpha测试，Beta测试）

软测方法：

白盒测试、黑盒测试、灰盒测试

软测类型：

功能、界面、安全、兼容性、易用性、性能、压力、负载、恢复测试等

其他测试分类：冒烟测试、回归测试、探索性测试

常用的开发的模型：V模型

软件测试的分类

什么是黑盒测试？

黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。不考虑内部结构，在程序接口进行测试。

Alpha、Beta测试的区别？

Alpha测试：前期的用户测试，公司内部在模拟实际操作环境下进行的一种验收测试。

Beta测试：后期的用户测试，此时已经通过内部测试，即将真实发布，是软件的在一个或者多个用户的实际使用环境下进行的测试

冒烟测试和回归测试区别？

冒烟测试：在新版本出来的时候，将软件的全部功能过一遍，功能可以正常进行不会影响测试进度，这个版本就可以真正测试了

回归测试：对以前版本中发现的bug在新的版本中验证是否存在且是否引发新的bug

1、边界值：

选取等于、刚刚大于、刚刚小于边界的值作为测试数据

基本思想是在最小值、略高于最小值、正常值、略低于最大值和最大值等处取值

2、等价类划分：

等价类划分就是把程序的输入域划分成若干部分，然后从每部分选取少量的具有代表性的数据作为测试用例。

无效等价类：不合理的、无意义的输入数据结婚，验证程序处理意外数据的能力

有效等价类：有意义的输入数据的集合，检验程序是否实现了规格说明总的功能和性能

等价类划分方法：按区间划分、数值划分、数值集合划分、限制条件和规则划分

3、错误推算法：

进行错误的操作，验证程序是否对出错的场景和情况有些应对能力，来选择测试用例数据

4、因果法/判定表法：

将判定表的每一列作为依据，设计测试用例。检查输入条件的各种组合情况

5、场景法：

通过描述的业务流程，设计用例来列出不同业务场景，作为测试用例的测试数据

基本流：主要是功能的正常操作流程

分支流：需要程序做非法判断处理的

* 测试用例方法的选择*（划重点）

1、进行等价类划分，主要是输入条件的划分，这是提高测试效率最有效的方法

在任何情况下都必须使用边界值分析法，这种方法设计出测试用例发现程序错误的能力最强

2、用错误推测法追加测试用例

3、如果程序说明中含有输入组合情况，则一开始就用判定表法（判定表法很少用到）

4、如果还没有达到覆盖标准，应当再补充足够的测试用例（场景法）

1、列出需求文档中的可测试性的原始需求

2、对每一条需求进行细化分解，形成可测试的测试点

3、针对测试点确定执行适合的测试类型

4、建立测试需求分析矩阵，对测试需求进行管理

软件测试需求的 重点 是“ 测什么 ”。

测试需求分析的目的：获取测试点，根据测试点编写用例

按钮指示灯：按压上下按钮指示灯是否亮

电梯门开关：按压上下按钮电梯门在当前楼层是否能打开

按向上按钮：电梯是否关门且向上面楼层方向走

按向下按钮：电梯是否关门且向下面楼层方向走

当电梯门没有关上：按开电梯门按钮，门是否开

当电梯门没有关上：按关闭电梯门按钮，门是否关闭

电梯内：按各个楼层，对应的指示灯是否亮

电梯内报警装置：报警装置是否正常

电梯内通话设备：按通话按钮能否接通外界

电梯内灯光：电梯内灯光是否亮，是否有无损坏

电梯内通风：是否通风

按各个楼层按钮：是否到当前楼层停止并开门

当超过最高重量：电梯是否报警打开电梯门，直到小于最高承重

电梯当前楼层是否和电梯内显示屏楼层一直

显示屏内是否有当前楼层，当前向上或者向下箭头，且与当前操作一致

电梯门超过规定时间未关门是否会有报警提示

上下按钮是否控制一个电梯或者两个电梯的开关门，如果控制两个电梯，按向上或者向下按钮，另一个电梯是否受控制

电梯是否分单双层？

在单层电梯情况下，按双层电梯，对应双层电梯数字是否亮，是否会到这一层

在双层电梯情况下，按单层电梯，对应单层电梯数字是否亮，是否会到这一层

电梯限层：按超过限层的电梯层数，数字是否亮，是否会到这一层

双击某楼层：是否会取消这个楼层且楼层灯灭

假如我在9楼，有人先按12楼，有人后按1楼，此时电梯是否先上12楼，再下1楼？

电梯感应：有人或者物体在门中间卡着，门是否会关闭，是否会有警铃提示？

电梯到达指定楼层是否有声音提示？

电梯是否刷卡：刷卡的电梯，如果没有刷卡是否能选楼层

维修开关：电梯内是否有维修开关

测试用例：指导性执行测试，帮助证明软件功能或发现软件缺陷的一种说明。每一个测试点的数据设计和步骤设计。

测试用例的重要性：

（1）、便于测试计划的实施

            一般主要适用于集成测试、系统测试、回归测试。根据用例知道自己的进度

（2）、规划测试数据的准备

            比如测注册，要提前准备好手机号、身份证号、不重复的用户名，邮箱等

（3）、编写测试脚本的根本

            自动测试的中心任务是编写测试脚本。测试脚本就是以测试用例为基础。

（4）、评估测试结果的基准

            通过测试用例的覆盖性和错误率，可以判断测试的结果，是否能发布

（5）、分析缺陷标准

 收集缺陷，对比测试用例。分析是漏测还是缺陷复现。反应了测试的不完善，应立即补充相应的测试用例

*测试标题如何写：测试点，对测试点进行细化分解。比如：输入正确用户名、密码，能否正常登陆。

测试用例编写格式注意：

（1）、测试标题一定要描述测试点（验证什么写什么），简洁明了，不存在重复

（2）、测试步骤要有指导性的意义，涉及测试数据输入最好包含具体的测试数据

（3）、预期结果是唯一的，不能出现“发送成功或失败”

如何编写测试用例？

用例包含：用例编号、功能模块、用例标题、前提条件、操作步骤、期望结果（含判断标准）、实际结果、备注

编写方式：按照功能+业务逻辑

（1）、首先保证单个功能是正常的

（2）、然后功能联合起来的业务逻辑是对的

比如：登录、充值、提现功能都是好的。业务逻辑，就是把所有的功能联合起来走一遍，看是否是好的

用例覆盖：包含正面和反面的用例

（1）、正面用例：根据功能模块划分，针对要测试的功能模块，所有正常输入数据的测试用例都写出来

（2）、反面用例：例如登录失败等，输入非法数据，违反唯一约束等等 关于接口测试用例编写原则和接口测试用例编写原则有哪些的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 接口测试用例编写原则的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口测试用例编写原则有哪些、接口测试用例编写原则的信息别忘了在本站进行查找喔。

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