微信接口测试用例（微信接口测试用例怎么写）

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

本文目录一览：

• 1、postman微信公众号接口测试
• 2、水杯，微信红包，电梯，朋友圈点赞，黑白灰盒，微信支付等测试用例
• 3、什么是接口测试?
• 4、微信域名检测官方接口及使用教程
• 5、一、测试理论、测试计划、测试用例

postman微信公众号接口测试

1、拿到api接口文档：熟悉接口业务、接口地址、鉴权、入参、出参、错误码

2、接口测试计划和方案：正例、反例、分页异常

3、编写用例和评审

4、执行接口测试

5、输出接口测试报告

在企业中做接口测试是不会把参数写死过去的

时间戳：

生成0-100的随机整数：

生成一个GUID的字符串：

一个接口中可能存在多个环境如：开发、测试、生产环境

环境和globals都是全局变量

多个接口之前都是有相互关联的

如：注册之后就是登陆，一个业务增删改查不可能一个接口一个接口测

如果一个参数可能从新增到修改再到删除D都是关联，则需要在第一个接口先去获取到，然后在下面接口使用时可以调用

可以在Tests界面上使用

1、json提取器

2、正则表达式提取器

3、cookie提取器
精确断言： 如果需要精确断言的，即这个是个变量，可以提取获取到值，保存到一个全局变量中，并通过获取全局变量来进行断言

一般是在这个Pre-request Script界面上
全局断言： 就是所有接口都用到这个断言

一般用于状态断言

水杯，微信红包，电梯，朋友圈点赞，黑白灰盒，微信支付等测试用例

功能

1.在红包钱数，和红包个数的输入框中只能输入数字

2.红包里最多和最少可以输入的钱数  200  0.01

3.拼手气红包最多可以发多少个红包  100

3.1超过最大拼手气红包的个数是否有提醒

4.当红包钱数超过最大范围是不是有对应的提示

5.当发送的红包个数超过最大范围是不是有提示

6.当余额不足时，红包发送失败

7.在红包描述里是否可以输入汉字，英文，符号，表情，纯数字，汉字英语符号，

7.1是否可以输入它们的混合搭配

8.输入红包钱数是不是只能输入数字

9.红包描述里许多能有多少个字符   10个

10.红包描述，金额，红包个数框里是否支持复制粘贴操作

12.红包描述里的表情可以删除

13.发送的红包别人是否可以领取

13.1发的红包自己可不可以领取   2人

14. 24小时内没有领取的红包是否可以退回到原来的账户

14.1  超过24小时没有领取的红包，是否还可以领取

15.用户是否可以多次抢一个红包

16.发红包的人是否还可以抢红包   多人

17.红包的金额里的小数位数是否有限制

18.可以按返回键，取消发红包

19. 断网时，无法抢红包

20.可不可以自己选择支付方式

21.余额不足时，会不会自动匹配支付方式

22.在发红包界面能否看到以前的收发红包的记录

23.红包记录里的信息与实际收发红包记录是否匹配

24.支付时可以密码支付也可以指纹支付

25.如果直接输入小数点，那么小数点之前应该有个0

26.支付成功后，退回聊天界面

27.发红包金额和收到的红包金额应该匹配

28.是否可以连续多次发红包

29.输入钱数为0，"塞钱进红包"置灰

性能

1.弱网时抢红包，发红包时间

2.不同网速时抢红包，发红包的时间

3.发红包和收红包成功后的跳转时间

4.收发红包的耗电量

5.退款到账的时间

兼容

1.苹果，安卓是否都可以发送红包

2.电脑端可以抢微信红包

界面

1.发红包界面没有错别字

2.抢完红包界面没有错别字

3.发红包和收红包界面排版合理，

4.发红包和收到红包界面颜色搭配合理

安全

1.对方微信号异地登录，是否会有提醒   2人

2.红包被领取以后，发送红包人的金额会减少，收红包金额会增加

3.发送红包失败，余额和银行卡里的钱数不会少

4.红包发送成功，是否会收到微信支付的通知

易用性(有点重复)

1.红包描述，可以通过语音输入

2.可以指纹支付也可以密码支付

界面测试：

外观（里面、外面）美观性

电梯空间尺寸是否和设计尺寸一致

按钮是否清晰和易懂

显示楼层的显示屏是否安装

是否联系外界的电话、紧急电话

设备检测说明书

安全规范说明书

灯

标识的承重和人数

扶手

镜子

仅提供可到达楼层的按钮

电梯制作的材料

空调

摄像头

功能测试：

测试电梯能否实现正常的上升和下降功能，每层是否都可以停靠。

每层停靠楼层是否与所按的楼层一致

电梯按键在按下时是否点亮按键灯

电梯在每个楼层的上行和下行的申请是否可以有效

电梯满负载的时候，是否会忽略其他楼层外部的上行和下行申请

电梯的两边按钮是否都可以使用，三列按钮。

电梯的楼层选择是否可以取消

电梯门的打开，关闭是否正常关闭（自动关闭）。

报警装置是否可用。（满载）

超重时是否能强制关门

超重时重新挪动一下人员是否可以上下行

与另外一部电梯之间是否协作良好。（算法）

电梯的灯光是否满足看书的要求

联系外界的电话是否可用

通风状况如何，人多的时候是否会很热，通风不畅（排气扇）

电梯里面的摄像头是否可用，拍摄是否清晰

门不夹人

伸手的话，应该不会强制关门

管理员可以和内部人通话

在各种场合下，可以强制开门

运行中时，不能按开门键，不会强制开门

在不同情况下（如：有人挡着、马上关门的时候、停电的时候、没有请求的时候…），一直按开门键和关门键

从电梯外部可以强制开门

模拟不同天气（温度，湿度，风速）下的测试

进入电梯，拨打手机，是否有信号

进入电梯喊话，外面是否能听到

楼层显示屏显示的楼层、以及电梯运行升降状态是否正确

两台电梯能否同时使用（或停用）

其中一台使用，另一台是否可以停用

一台电梯报错，另一台可以正常

A电梯按上行，B电梯按上行

A电梯按上行，B电梯按下行

A电梯按上行，B电梯按上下行

A电梯按上行，B电梯按下上行

A电梯按下行，B电梯按下行

A电梯按下行，B电梯按上下行

A电梯按下行，B电梯按下上行

A电梯按上下行，B电梯按上下行

A电梯按上下行，B电梯按下上行

电梯空时如何运转

电梯门开时不进电梯

进入电梯后不做任何操作

电梯门开的时间多长，超过时间后是否自动关门

电梯门开的时间超时后关门到最后2厘米，是否可以撬开门

电梯门关闭后还未上升时，电梯外按下上行（或下行）按钮，电梯门是否会打开

电梯最底层是否有下行按钮

电梯最顶层是否有上行按钮
停靠算法测试：

2部均空闲时，采取就近原则，离乘电梯人最近的电梯优先运行；

有1部运行时，以同行方向且顺路的电梯优先运行，否则安排空闲电梯；

2部均运行时，以方向通行且顺路的电梯优先运行；

每部电梯，在电梯内部每层在上升和下降过程中，再电梯内部均申请每层停靠

每部电梯，在电梯内部每层在上升和下降过程中，再内部没有任何申请的情况下，在电梯外部均申请每层停靠

每部电梯，在电梯内部每层在上升和下降过程中，再电梯内部均申请每层停靠，在电梯外部也申请每层停靠

电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来

电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。

类似7、8测试步骤地随机测试，在电梯内部和外部均有不同组合申请的情况下，验证楼层停靠是否准确和合理。

电梯本来在2楼，1楼按上行键的同时3楼按下行键，查看优先上行还是下行

电梯的平稳性，是否会上升过快或者下降过快，造成人体不适应反应

可靠性：

无任何申请的时候，可以长时间停留在某层，并且门是关闭的

门关上的一刹那出现障碍物。

长期有障碍物在门口堵住，电梯应该也不会关门或上升和下降

同时按关门和开门按钮。

快速交替按关门开门按钮

点击当前楼层号码。

快速点击不同楼层

上升到顶层后，电梯中的原有下楼请求均会被取消

下降到负楼层后，电梯中的原有上楼请求均会被取消

电梯外部同时按上键和下键会怎样。

长按打开按钮，电梯门是否持续打开

突然停电或超载时的情况，电梯（停靠、正在上升、正在下降）不会坠落，电梯门可以通过外力打开，并且紧急电话可用

电梯运行中，申请马上要经过的楼层停靠，电梯应该不会停靠。

在电梯里面蹦跳，电梯不会出现不稳定的情况。

电压不稳定的情况下的电梯运行情况

电梯不能正常工作的时候是否有监控系统自动报警

电梯不能正常工作的时候，是否有流程可以精确的指定到人进行所有故障解决的高效处理

意外坠梯时所有按键正常使用
易用性：

电梯的按钮的设计符合一般人使用的习惯吗．

按钮是否考虑残疾人和小孩儿

楼层显示屏是否处于电梯的上部，方便别人看到
可维护性

是否有方便维修和维护电梯的工作条件（竖井通道、统一断电等）

电梯的常用配件是否容易更换

电梯的维修成本如何

电梯的安装、维护、测试

超过维修年限，是否可以正常运转

竞品测试

和其他厂家的产品比较，验证产品的竞争力

关门速度

启动速度和上升速度是否会造成人的不适应

上升和下降的速度是否满足用户要求

2部电梯的一个对比
配置测试

针对电梯系统的不同运行参数进行配置，并验证所有配置项是否可以生效

负载/压力测试：

看电梯的最大限度的承受重量．在负载过重时是否有提醒。

频繁的关门、开门操作

耗电量测试

上升和下降不同楼层的速度，是否有明显的延迟

多次按压按钮，确认所有按钮正常使用

长时间按压一个按钮不放开，确认所有按钮长时间按压功能正常
兼容性测试：

电梯是否适用于不同写字楼、不同国籍、不同地区
稳定性测试：

最大负载下平稳运行的最长时间、不断地高负荷运行。7*24小时

无负载下平稳运行时间。7*30 小时
文档测试：

文档是否齐备，能否描述具体的信息，满足安装公司、使用者、维护公司的使用要求

安装手册：安装的条件、方法、流程、检测标准、试运营要求和最后交付条件

电梯使用说明书:最大承载说明、正常使用的温度、湿度、电压等条件

维护说明书：如何进行电梯的维护、检测和维修，需要定期更换的配件

安全说明书：如何在停电、电压不足、超重的情况下保证电梯的安全性，以及在出现特殊运行情况时的处理方法
黑盒测试

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑构造和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫 功能测试 或者 数据驱动测试。

黑盒测试主要是为了发现以下几类错误：

1.是否有不正确的遗漏的功能？

2.在接口上，输入是否能正确的接受？能否输出正确的结果？

3.是否有数据结构错误或外部信息访问错误？

4.性能上能否满足要求？

5、是否有初始化或终止性错误？

具体的黑盒测试方法包括等价类划分、因果图、正交实验涉及法、边界分析、判定表驱动法、功能测试等。

白盒测试

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或者选择测试用例，对程序所有的逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为 结构测试 或 逻辑驱动测试。

白盒测试主要是想对程序模块进行如下检查：

1.对程序模块的所有独立的执行路径至少测试一遍。

2.对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

3.在循环的边界和运行的界限内执行循环体

4.测试内部数据结构的有效性等等

白盒测试方法包括：语句覆盖、判定覆盖、条件覆盖、条件组合覆盖、路径覆盖等

以上事实说明，软件爱你测试有一个执行的缺陷，即测试的不完全、不彻底。由于任何程序智能进行少量（相对于穷举的巨大数量而言）的有限的测试，在未发现错误时，不能说明程序中没有错误

灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间，可以这样理解，灰盒测试关注输出对于输入的正确性，同事也关注内部表现，但这种关注不像白盒那样详细、完整，只是通过一些表现性的现象、时间、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒测试方法。
UI测试：

导航栏元素位置、大小、颜色等要素是否一致/是否符合UI效果图；

导航栏视频分类下拉框位置、颜色、按钮是否正确

鼠标滑过、点击时、点击后按钮状态是否有相应颜色、状态变化；

视频列表页面title、视频图片、视频title、是否付费等元素的颜色、大小、位置等是否正确；

视频播放页面：视频title、视频默认加载图、播放按钮、目录、视频列表、视频介绍等元素位置、大小、颜色、鼠标操作时状态是否与预期一致；

视频播放时进度条、快进按钮、快退按钮、播放按钮、暂停按钮位置是否正确

功能测试：

首先判断用户是否登录，未登录不能进入主页（应提示用户先进行登录），已登录状态用户可以进行视频观看；

导航栏下拉框是否可以正确打开和关闭，打开和关闭时的状态是否和预期一致；

鼠标滑过、点击时、点击后相应条目的状态是否和预期一致；

点击相应条目时，页面右边是否同步切换至相应页面，是否有延时、卡退、切换错误等情况；

视频播放页面鼠标滑过、点击时、点击后视频对应条目、标题是否有相应状态变化（具体变化状态根据产品原型进行分析），点击后是否能够正确跳转至相应的视频播放界面；

判断用户点击的视频属于免费还是付费，如果为免费则所有人均可以进行观看，如果为付费则要判断用户是否付费，如果已经付费则可以进行观看，如未支付则提示用户先购买后再进行观看并提供支付入口或者联系客服进行支付的方式；

进入视频播放界面判断当前视频title是否和用户上一步点击的视频title一致；

视频默认加载图是否显示正确或者显示异常等情况；

视频播放按钮是否可以点击，点击后视频是否正常播放；

视频目录是否显示正确，如有子列表是否正常显示，如果没有子列表是否有相应提示（具体效果根据产品原型进行分析）；

视频介绍是否与当前视频一致，讲师是否一致等情况；

点击播放后进度条是否随之变化；

视频快进、快退、暂停、播放是否可以正常使用，是否有卡顿、延时、闪退等情况；

播放完成后是否自动切换下一视频（如有多节视频情况下，如果只有一条子视频的情况下，播放完成后是否关闭当前页面或者给予用户相应提示），如果需要手动切换是否有相应的友好提示；

视频播放时声音、画面是否一致或者是否有异常等情况；

视频最大化、全屏、最小化是否可以正常使用，切换时是否有卡顿、延时等情况；

当前视频与其他视频来回切换时，视频是否有卡顿、延时等情况；

电脑关机或者其他异常情况下，视频是否会保存播放记录，下次进入观看时是否继续上次的播放记录继续播放；

兼容性测试：

平台兼容性：Windows、Mac

系统兼容西：Win7、Win10、Mac

屏幕分辨率：不同电脑显示器分辨率不同，视频相关页面是否有模糊、适配是否合理；

播放器是否与其他类型播放器冲突（例如音乐播放器打开后，视频是否暂停还是继续播放）；

网络测试：

网络切换测试：无线网与宽带；

弱网测试：弱网情况下视频是否卡顿、画面是否失帧；

无网络状态进入是否会有相应提示；

网络切换时视频是否暂停、保存当前播放状态；

易用性测试：

界面是否一目了然（比如：视频title、片头、片尾、视频画面等）；

视频页面操作是否方便，菜单栏是否正确、易上手；

进度条拖拽使用起来是否方便；

视频是否具有视频记忆功能/是否保存当前播放进度

什么是接口测试?

1接口测试的定义与分类，以下就是接口测试
接口测试是测试系统组件间接口的一种测试。
主要用于检测外部系统与系统之间以及系统内部各个子系统之间的交互点。
重点测试数据的交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系等等。
这要求对业务逻辑有一定程度上的理解，对数据流向有较好的定位。
接口测试般会用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。
接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。
接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。
接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比。
接口测试天生为高复杂性的平台带来高效的缺陷监测和质量监督能力。平台越复杂，系统越庞大，接口测试的效果越明显。
接口测试的目的是测试接口，尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换、传递和控制管理过程，还包括处理的次数。外部接口测试一般是作为系统测试来看待的。
不是所有的团队都可以在一个隔离的测试环境中进行测试工作的，因此使得对外部接口的测试显得困难。
我们应该确保较早地与相关的组织协调好并确定进行外部接口测试的方案。
有时候相关的组织只是人工的静态的审阅一次数据而并不真正的用这些数据来测试，这些都增加了实际测试执行中遇到的风险，但有些时候是可以避免的。
接口测试有的公司是归纳在集成测试里面，也有的公司会放在系统测试阶段，不过这个都没有什么区别，本质上接口测试就是通过某个功能模块对外暴露的一个接口地址传参进行测试。
一般来说接口分为如下三类：
A. 系统与系统之间的调用(如我们一般常见的分享内容到朋友圈或者是微信朋友时，微信会提供接口给这些需要用到分享的应用)上层服务对下层服务的调用（这个理解难度稍微有点大，在我们程序中功能是分层的，那么属于上层对底层服务的调用，以后能够有机会接触到代码或者更加稍微复杂点的接口测试就能够理解。举个例子，我们的程序框架分为三层，分别是web层：提供给用户请求的层次；feb迁至层：作为信息传递的中转站；service层：作为程序应用的核心，处理所有的请求
C.服务之间的调用（如添加一条数据时，会先调用数据查询的服务，查询该数据是否是重复数据）
不同类型的接口测试方法可能不一致，但总体来说不管是哪种类型，被测接口即为服务，测试手段为客服方，接口测试的目的就是：通过我们的测试手段，去验证满足其申明提供的功能。
2如何做接口测试
接口测试的原理：通过测试程序模拟客服端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端，客户端接收应答报文这一过程（reques-response）。
接口测试的流程与功能测试有什么区别呢？从原则上以及流程上讲，是没有啥区别的，都同一套软件测试流程：需求讨论-评审需求-确定需求-产出接口定义-根据需求文档及接口定义设计测试用例（测试用例主要从业务场景，功能以及异常测试几个方面考虑）-评审用例-执行测试。
接口测试采用的最基本的就是黑盒测试，在这个测试过程中我们最需要关注的是，如何来设计测试用例，设计测试用例所采用的方法也是我们常所用的几大方法：等价类、边界值以及错误推测法、场景法。在设计测试用例之前，我们先来看看常见的接口文档形式。
这就是上图是一种比较规范的接口文档说明，包含了如下内容模块：接口的类型说明、接口地址、http请求方式、输入参数和请求接口后返回的响应结果。
接口测试编写测试用例，主要关注点是输入参数、输出结果以及内部业务逻辑是否正常‘，所以我梦设计用例也要从这几方面出发考虑：
a）输入参数测试：针对输入参数进行的测试，也可以说是假定接口参数的不正确性 进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法（不合法），输入参数为空，为null,输入参数超长等等；
b）接口是否满足了所提供的功能，相当正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例就有更好的可读性和可维护性；
c）逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试的界限并不是那么清晰，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常；
d）异常情况接口测试：接口实现是否对异常情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何异常都进行处理；
针对上面的注册接口，我们利用测试用例设计方法来编写测试用例，如下所示：
3接口测试的工具选择
可以进行接口测试的工具有很多，这里简单介绍几个：
loadrunner :一款商业性能测试工具，用来做接口测试，很好很强大。
jmeter :一款开源的性能测试工具，操作简单方便，既有jdbc request 操作数据库数据，也有http request 和 soap request 应对测试；
httprequester :火狐浏览器自带接口测试工具，插件中安装即可，界面简单明了，容易上手。
postman :谷歌浏览器的扩展工具，界面简洁，开发者比较常用的一款插件工具。
soapui : 开源测试工具，通过soap/http 来检查、调用、实现web service的功能/负载/符合性测试。
我们将在后面的教学中，重点讲解Jmeter这款综合性比较高的工具；

微信域名检测官方接口及使用教程

微信域名检测接口 是腾讯官方对外公布的域名查询api，请求api接口可实时查询域名在微信中的状态信息。如果状态异常则返回结果提示“域名被封”，如果未有异常则返回结果提示“域名正常”。

测试地址： https://www.urlzt.com

可检测到域名的四种异常情况：

1、链接报红：提示已停止访问该网页

2、安全提示：提示非官方网页

3、安全提示：提示网址包含过多重定向

4、拦截提示：请长按复制链接使用浏览器访问 应用场景
接口地址: http://api.new.urlzt.com/api/vx

请求方式: GET/POST

请求示例: http://api.new.urlzt.com/api/vx?token=Tokenurl=www.urlzt.com

接口说明：将Token值进行复制或者直接复制请求示例api链接

一、测试理论、测试计划、测试用例

1.软件定义：一系列按照特定顺序组织的计算机数据和指令的集合。

                    软件=数据 + 指令

2.软件的分类：

    (1)类型：工具类软件、游戏型软件、媒体型软件、电商型软件等

    (2)架构：

        ①单机软件：office、红警等

        ②分布式软件：

            C/S架构软件：客户端需安装专门软件，如QQ 微信等

            B/S架构软件：客户端为浏览器 ，如百度、hao123等

            *面试题：C/S和B/S的区别

3.软件测试:

    定义：通过人工或自动化的方式来验证软件的实际结果与用户需求是否一致的过程

    原则：

        1.测试显示软件存在缺陷

        2.穷尽测试是不可能的

        3.测试尽早介入

        4.缺陷集群性（2/8原则）

        5.杀虫剂悖论

        6.测试活动依赖于测试内容

        7.没有错误是好是谬论

4.测试模型：

    1.V
    2.W
    3.H

    4.X

5.测试流程

        *角色：项目总监、产品经理、UI设计、项目经理（项目总监）、开发、测试

        *面试题：测试流程

6.软件分类

    (1)技术：黑盒测试、白盒测试、灰盒测试

    (2)阶段：单元测试、集成测试、系统测试、验收测试

    (3)其他：冒烟、回归、随机、兼容、内测、公测
1.模板

    (1)测试目的：测试内容、最多遗留bug、上线时间

    (2)测试资源

        ①人力资源：岗位、姓名、职责

        ②软件资源：浏览器、操作系统、DB、运行环境、服务器

        ③硬件资源：手机、电脑、平板、机器人、汽车

        ④网络资源：互联网、局域网

    (3)测试范围

        ①测试对象

        ②测试特性

        ③测试非特性

    (4)测试进度：任务、测试人员、预期开始时间、预期结束时间、时间进度、备注

    (5)测试风险

        ①内容：人资源环时

        ②模板：风险编号、风险描述、责任人、风险等级、对项目的影响、规避方法

    (6)测试准则：启动、暂停、再启动、停止准则

    (7)人员分工：岗位、姓名、工作内容

    (8)测试策略、功能测试、接口测试、接口测试、兼容测试、性能测试、易用性、安全测试

    (9)测试输出

        ①模板：文档名称、文档编号、编写人、文档详情

        ②内容：测试计划、测试用例、测试报告、缺陷报告

2.如何写

    (1)封面

    (2)九大项：标题  填内容

    (3)插入目录

    九大项：测试目的、测试资源、测试范围、测试风险、人员分工、测试策略、测试准则、测试进度、提交测试文档。

只要第一项和最后一项的位置是固定的，其他都可以微调位置
1.测试用例概述

    (1)定义：执行测试的用例

    (2)原因

    (3)如何保证高质量的测试用例：

        ①覆盖率

        ②简单明了

        ③符合需求

        ④用最少的用例覆盖最多的需求

    (4)方法：等价类划分、边界值分析法、场景法、错误推断法、因果图法、正交实验法

2.设计测试用例方法

    (1)等价类划分

        ①定义：把所有可能输入的数据分为若干个区域，然后从每个区域中取少量有代表性的数据进行测试。

        ②分类：

            1)有效等价类：符合需求的数据

            2)无效等价类：不符合需求的数据

        ③案例：

            1)手机号案例

            2)实名认证

    (2)边界值分析法

        ①定义：取稍高于或稍低于边界的一些数据进行测试

        ②取点：

            1)左上点：边界坐点

            2)右上点：边界右点

            3)左离点：闭外开内

            4)右离点：闭外开内

            5)内点：区间任意一点

        ③边界值和等价类划分分法去重：内点和有效等价类一个点重复

    (3)场景法

        ①定义：模拟用户场景

        ②分类：

            1)基本流：正确的流程

            2)备选流：不正确的流程

        ③案例：注册

    (4)因果图法

        ①定义：因果图法比较适合输入条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

        ②案例：自动售货机

    (5)错误推断法

        ①定义：经验丰富的测试工程师

        ②案例：手机无法拨通

    (6)判定表法

        ①定义：设计测试用例时，分析和表达多输入条件下执行不同操作的黑盒测试方法。

        ②案例：修车

    (7)正交实验法

        ①定义：使用正交小助手

        ②案例：字符设置

3.用例核心要素

    必须掌握：用例编号(如何命名)、所属模块、用例标题（验证谁在什么情况下，去做什么，最后结果是什么）、优先级、前置条件、操作步骤、测试数据、预期结果、实际结果

    了解内容：通过否、bugID、编写人员、编写时间、测试人员、测试时间、备注 关于微信接口测试用例和微信接口测试用例怎么写的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 微信接口测试用例的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于微信接口测试用例怎么写、微信接口测试用例的信息别忘了在本站进行查找喔。

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