【精通Postman接口测试】03-结果断言实战 + 数据驱动保姆级教程

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨ 🎯 你正在阅读「接口测试从入门到跑路」系列文章 🎯 ✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

🔥 弹简特 个人主页

❄️ 个人专栏直通车：

• 💻 软件测试入门记
• 📱 野生测试修炼手册 | APP 专项测试笔记
• 🔌 接口测试从入门到跑路
• ☕ 一个后端的 JavaEE 续命指南
• 🛜 网络原理续命手册

✨ 靠热爱去书写自己，靠勇敢去书写生活！ ✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

🌟 博主简介:

文章目录：

• 前言
• 一、Postman接口测试结果断言
• • 1、Postman中的断言函数
  • • 1.1 Status code: Code is 200
    • 1.2 Response body: Contains string
    • 1.3 Response body: JSON value check
    • 1.4 Response body: Is equal to a string
    • 1.5 Response headers: Content-Type header check
    • 1.6 Response time is less than 200ms
  • 2、实战演示
  • • 2.1 案例1：`一般`对于返回值是动态的我们就看一下他是否包含
    • • 1） 状态断言
      • 2） 业务断言
    • 2.2 案例2：对于返回值是固定的我们就看他是否等于(系统值就是固定的)
    • • 1） 状态断言
      • 2） 业务断言
  • 3、公共断言
  • • 3.1 公共断言加在哪里才能让各接口共用
    • • 1）点击项目名->选择脚本
      • 2）把你的代码粘贴上去
  • 4、精确断言
  • • 4.1 思路
    • 4.2 实操
    • • 1）在请求前自己先生成一个系统时间
      • 2）构造请求的时候取到这个时间
      • 3）断言的时候从集合变量中将这个随机数取出来
      • 4）测试看是否成功
  • 5、加断言之后批量运行有结果了
• 二、Postman接口测试数据驱动
• • 1、方式一：通过批量运行中的数据文件来实现数据驱动（只能测单个接口，不要选择多个）
  • • 1.1 实操
    • • 1）测试用例
      • 2）根据测试用例编写数据驱动文件
      • 3）在Postman中选择数据文件
      • 4）从数据文件中去取值
      • 5）开始测试
  • 2、方式二：通过文件结构实现正反例的测试(非数据驱动，但可达测试效果)
  • • 2.1 实操
    • • 1）首先右键项目，新建一个目录
      • 2）将我们的获取token接口的正反例放到里面进行管理
      • 3）同样复制一样的获取token接口的两个接口，并起名字
      • 4）构造正反例请求
      • • 反例1：没有appid
        • 反例2：没有secret
        • 正例：完整参数
      • 5）最后一步：批量运行这三个测试用例
• 三、写在最后

前言

👋老铁们，玩 Postman 做接口测试的时候，断言绝对是必备干货神器！有了它，就能轻松判定接口到底通没通、返回数据正不正常～ 还有大家常用的数据驱动用法，我全都给你们安排上了🙌 全程保姆级手把手教学，配图 + 实操步骤一步不落下，每个功能用法都拆解得明明白白，新手也能轻松看懂！话不多说，咱们直接开整～👇

一、Postman接口测试结果断言

截此为止，我们测过的所有接口，都没有添加断言，此时你是不容易看出他是否是对还是错的。 比如说上一篇博客中，我们的批量运行里面，它的结果也没有显示是对还是错，因为你没有添加断言。

一般我们的断言有两种：

• 状态断言：断言它的响应码
• 业务断言：断言它的业务数据 一般一个接口，我们都用这两种

1、Postman中的断言函数

如图所示，点击Postman里面的脚本，你会看到对应的函数，以及你点击它之后会生成对应的代码。

1.1 Status code: Code is 200

意思：检查 HTTP 状态码是不是 200 作用：确认服务器正常处理了你的请求，没报 404、500 之类的错误。就像打电话，对方接起来了，而不是“您拨的电话已关机”。

1.2 Response body: Contains string

意思：检查返回的内容里有没有包含某个字符串 作用：不要求返回值一模一样，只要里面有你要的关键词就行。比如返回了一大串 HTML，你能确认里面有“登录成功”四个字。

1.3 Response body: JSON value check

意思：检查返回的 JSON 里某个字段的具体值 作用：这就是针对 JSON 接口的精准断言。比如 {"code":0}，你必须确认 code 就是 0，而不是别的。

1.4 Response body: Is equal to a string

意思：检查返回的整体内容恰好等于一个字符串 作用：严格匹配，一字不差。适合返回值特别简单且固定的情况，比如某个接口只回一个纯文本 “OK”。

1.5 Response headers: Content-Type header check

意思：检查响应头里有没有 Content-Type，或者它的值是什么 作用：确认服务器告诉浏览器“我返回的是 JSON”还是“一堆 JSON 数据”，防止前端接收到格式不对的内容。

1.6 Response time is less than 200ms

意思：检查接口响应时间小于 200 毫秒 作用：性能红线。超过这个数，你就可以喊开发过来看日志了。

2、实战演示

2.1 案例1：一般对于返回值是动态的我们就看一下他是否包含

1） 状态断言

跟着图中的步骤做 a、点击代码片段 b、选择状态码是不是200的代码

2） 业务断言

我们首先来看：他后端返回的token值，是不固定的 这个思路就是给我这个断言你有没有包含token值 a、点击响应包含某字符串代码 b、然后修改你的名字，将包含的名字改为你后端返回的access_token 结果

2.2 案例2：对于返回值是固定的我们就看他是否等于(系统值就是固定的)

1） 状态断言

a、点击代码片段，先检查状态码

2） 业务断言

a、测试返回结果有固定值 b、然后就找一下有JSON的那个代码片段，他是用来看结果是否等于某一个值的 c、去判断是否等于你的那个值

结果如下所示：

3、公共断言

什么叫做公共断言？它也叫做全局断言，比如我们上周的两个例子中，你每一个里面都去断言它的状态码为200，那你想了，这个我们可不可以提取出来呢？可以的，我们把它提取出来，它就是一种公共的断言，到时候他会让你每一个接口都去添加这个断言。

3.1 公共断言加在哪里才能让各接口共用

我们是加在项目级别的脚本里面，如下步骤👇

1）点击项目名->选择脚本

2）把你的代码粘贴上去

那此时你测试的时候，其他接口都会有这个状态断言

4、精确断言

首先回顾我们第1篇博客里面的项目实战，创建一个标签，我们当时因为标签名不重复的原因，我们给他加了一个随机数。

需要了解一下项目实战的铁子么课参考👉：项目实战

你看图👇 我们之前是给它拼接上了一个随机函数的，添加成功之后，它会返回我们指定的值，如图所示👇

4.1 思路

思路：现在我们用断言，要精准的匹配到这个广东后面加一个随机数的值，首先你是做不到的。 因为我们那个随机数，它是随机生成的，你很难做到精准匹配，这时候怎么办呢？ 我们不用那个系统自带的随机数函数：我们自己写一个，思路就是在请求之前，自己先生成当前系统的时间，并且我们把这个时间设置为一个集合变量，供给这个项目使用，然后我们构造请求体的时候去集合变量中取到这个系统时间，最后请求完之后呢，我们再取这个集合变量中的系统时间来进行精准断言。

4.2 实操

1）在请求前自己先生成一个系统时间

设置具体的值

2）构造请求的时候取到这个时间

3）断言的时候从集合变量中将这个随机数取出来

首先点击对应的代码 点击从集合变量中获取到的随机数函数 开始拼接精准字符串

4）测试看是否成功

注意get函数中是字符串 修改之后 结果：

5、加断言之后批量运行有结果了

我们加了断言之后，我们的批量运行就有是否通过的结果了，所以可以看出我们的断崖还是挺重要的。

批量测试的博客我也总结的很详细，可参考👉批量测试

运行项目： 查看结果：

二、Postman接口测试数据驱动

Postman中数据驱动其实用的比较少，相较于的话，我更喜欢用Jmeter中的， 为什么Postman中数据驱动其实用的比较少？

因为它所有的接口共用同一个数据文件，比如你有100个接口，那你这100个接口就只能用一个数据文件，这是比较不太好用的。

我们的数据驱动有两个方式

1、方式一：通过批量运行中的数据文件来实现数据驱动（只能测单个接口，不要选择多个）

这种方式很不可取，我们基本不用，原因：

因此我们在使用的时候，我们一般批量运行，选一个接口就行了，千万别选多个接口，你选完这个接口，然后去改他的数据文件，再搞下一个接口，比较麻烦。

1.1 实操

1）测试用例

2）根据测试用例编写数据驱动文件

Postman中的数据驱动文件的格式是.csv

我们先创建一个.csv文件，👇 向里面写入我们的数据

grant_type,appid,secret
client_credential,,e40a02f9d79a8097df497e6aaf93ab80
client_credential,wx74a8627810cfa308,
client_credential,wx74a8627810cfa308,e40a02f9d79a8097df497e6aaf93ab80

文件说明：

• 第 1 行：grant_type、appid、secret 三列头。
• 第 2 行：反例1 — appid 留空，secret 正常，对应错误码 41002。
• 第 3 行：反例2 — secret 留空，appid 正常，对应错误码 41004。
• 第 4 行：正例 — 三个参数齐全，能正常返回 access_token。

3）在Postman中选择数据文件

右键项目名–【选择run】–【选择对应要驱动的接口】–【选择数据文件】–【选择执行次数】

【选择你对应的接口，不要选全部】

【选择数据驱动文件】–【然后记得执行你的用例次数：3次】

4）从数据文件中去取值

使用{{字段名}}取值

5）开始测试

查看结果

注意哦：我们之前是加过断言的，所以你会很容易看出时候否测试通过 因此断言真的很重要

2、方式二：通过文件结构实现正反例的测试(非数据驱动，但可达测试效果)

第1种方式很不合理，我们基本不用，但是我们可以用第2种方式，但是这种方式不是数据驱动，所以这种方式没有数据文件，我们是需要去写正反例的测试接口，然后运行的时候就批量运行这些测试接口，我们看实操就懂了👇

2.1 实操

1）首先右键项目，新建一个目录

2）将我们的获取token接口的正反例放到里面进行管理

3）同样复制一样的获取token接口的两个接口，并起名字

起名字

4）构造正反例请求

反例1：没有appid

断言：方便测试报告中显示

//断言状态码
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});

//断言没有参数appid的时候返回值是否有41002
pm.test("Body matches string", function () {
pm.expect(pm.response.text()).to.include(41002);
});

反例2：没有secret

断言：方便测试报告中显示

//断言状态码
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});

//断言没有参数appsecret的时候返回值是否有41004
pm.test("Body matches string", function () {
pm.expect(pm.response.text()).to.include(41004);
});

正例：完整参数

断言：方便测试报告中显示

//断言状态码
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});

//断言参数完整的时候返回值是否有token
pm.test("Body matches string", function () {
pm.expect(pm.response.text()).to.include("access_token");
});

5）最后一步：批量运行这三个测试用例

右键项目名–【run】–【选择要运行的接口】 或者：右键你的目录–【run】

最后看结果：

ok，到这里，我们本期的结果断言和数据驱动就结束咯~

三、写在最后

🎯 看到这里，辛苦啦！歇一歇，喝口水，让眼睛放松一下 这篇笔记我写了很久，如果对你有哪怕一点点帮助，请点一下「关注」。 后面我还会继续分享很多自学干货笔记，都是自己边学边总结的，依然会是零基础能看懂、每一步都截图的那种详细笔记。 我是学生，没什么能送你的，只能保证每一篇都认真写、不藏私。 我能给的，就是一篇一篇亲手整理的、零基础也能看懂的干货笔记。 你的每一次关注，都是我继续写下去的动力。 谢谢你的时间，我们下一篇笔记见 👇 （如果这篇笔记有写错的地方，也请一定在评论区告诉我，我会第一时间修改）

下一篇见咯，兄弟们~~