【接口测试】什么是断言为什么要学习断言？

题主你好,

我先给你举个生活中的例子吧.

比如有个机器叫"红烧肉", 它的作用是将生猪赶进去,直接从另一边就出红烧肉了.

下面我们再来说断言, 拿上面的例子来说, "红烧肉"这个机器就是一个"断言", 它是别人已经发明好的, 我们只需要知道"红烧肉"这个机器的作用是你喂给它生猪,它就会直接输出红烧肉就够了,而具体这个"红烧肉"机器内部是怎么个复杂的流程如怎么杀,怎么去毛,怎么...这么一系列的步骤你都不用关心.

好,下面再举一个实际一点的例子, 假设我使用的软件有N个断言,其中一个叫做containString,它的作用是判断响应回来的内容中是否包含某个字符串, 你不用管containString到底是怎么查找字符串的, 你只需要知道我喂给它响应信息,它就能告诉我是否包含指定的字符串就够了, 如我实际的断言代码为:

containString "hello friend"

此时我的请求是http://1.1.1.1/

响应回来的内容是: 000 111 222

关键来了,此时就会将"000 111 222"喂给 containString这个机器, 而这个机器从"000 111 222"查找"hello friend"这个字段串, 此时肯定找不到,所以你本条接口测试用例就失败了,你需要提bug.

如果响应回来的内容是: "000 hello friend 111 222",则会将"000 hello friend 111 222"喂给containString这个机器,此时从"000 hello friend 111 222"中发现了"hello friend", 因此本条接口测试用例就通过了.

到此,我们再来想一下, 如果测试软件不提供给你containString这个断言函数,要你从响应信息中找到是否包含某个字符串,你怎么办, 用眼睛看? 不现实,我上面的例子返回的内容很简单,你能看出来, 但如果是返回1亿个字符呢?就没法人眼看了, 并且也不够方便.

所以我们要学习测试工具提供给我们的断言,我们只需要知道每一个断言是做什么的,怎么用就行了,而不必关心这些断言的实现逻辑有多复杂.

=====

希望可以帮到题主, 欢迎追问

postman的接口测试需要添加断言的方式对接口的判断，另外在tests中还可以进行很多的 *** 作协助测试工作，做了一个简单整理。

一、断言部分：

1.判断请求返回的状态码为200，200就是请求状态正常。

tests["判断返回的状态为200"] = responseCode.code === 200

2.判断请求返回的时间小于200ms，一般认证正常的请求应该在200ms之下。

tests["判断请求返回的时间小于200ms"]= responseTime <200

3.获取json数据并进行校对键对值的正确性

以下面的返回数据为例（之后的断言也是一这个返回为例）：

"status": 1,

"res": [

{

"id": 39,

"from": “东方”,

"to": “南方”

},

{

"id": 38,

"from": “西北”,

"to": “东南”,

}

]

1）先获取到返回的json数据：

var responBody = JSON.parse(responseBody)

2）断言status返回的值为1

tests["判断返回的status返回为1"] = responseBody.status === 1

3）断言res下第一个元素中from的值为东方

tests[“res中第一个元素中from的值正确”] = responseBody.res[0].from === "东方"；

4.判断数据返回类型是什么。我大概整理一下几种类型的：number 、string 、object 、array 、boolean 、undefind。

tests["判断res下第一个元素中id的返回元素为number"] = typeof(responseBody.res[0].id) === "number"

如果需要判断其他的类型就可以用同样的方法更换最后的类型就可以了。

5.判断返回数据中是否存在某个元素。这个虽然到现在一直没用得上，但是也是一个基础的断言语句了

还是以上面的返回数据为例子，判断返回元素中是否有status

tests["判断返回的元素中带有status"] = responseBody.has("status")

好了以上就是常用的几个断言语句了。。。

二、其他的 *** 作

1.将获取到的值设置为环境变量-->key变量名 value 环境变量值

pm.environment.set("key"，value)

2.设置流程控制跳转的下一条需要执行的接口-->requestname 为需要跳转的接口名

postman.setNextRequest(requestname)

3.判断一个字段返回的值是否在一个列表中出现过；

例子：接口A中返回的列表中的name字段的值，需要在B个列表中也出现且相等

for (var k=0k

tests["判断name是否相同"] = Alist.indexOf(Blist[k].name) >-1

}

Blist是B接口返回的数组，Alist是A接口返回的数组，通过遍历B数组查看是否有A数组中的name值，-1为没有的情况，所以使用 >-1判断是否存在

大家都知道，在软件测试特别是在单元测试时,必用的一个功能就是“断言”（Assert)，可能有些人觉得不就一个Assert语句，没啥花头，也有很多人用起来也是懵懵懂懂，认为只要是Assert开头的方法，拿过来就用。一个偶然的机会跟人聊到此功能，觉得还是有必要在此整理一下如何使用以及对“断言”的理解。希望可以帮助大家对此有一个系统的理解，也趁机聊聊“断言”发展一路过来的心路历程。

首先稍微介绍一下断言相关知识，对于有经验的程序员请移步到下面的“断言”进化史部分。

在单元测试时，程序员预计在程序运行到某个节点位置，需要判断某些逻辑条件必须满足，这样下面的一些业务逻辑才可以进行下去，如果不满足，程序就会"报错"甚至是"崩溃"。比如说，一段程序是负责“转账”，在真正开始转账 *** 作前首先需要“断言”这个账户是一个“合法”的账户，比如账户不是 null 。当出现些状况时，程序开发人员就可以在第一时间知道这个问题，可以去 debug 除错，而非等到交付给用户后才发现问题。其实这个功能是TDD (Test Driven Develop)的基石之一。

一开始的一些单元测试框架（比如JUnit）提供的断言语句，这样在程序某个地方确保某个逻辑关系肯定返回是true,如果不是true,这个单元测试就是没有测试通过。如下就是一个例子,如果程序运行到此行时返回false程序就会抛出一个错误（如下图一）并停止运行，开发人员可以去检查下为什么出现此问题。非常的简单粗爆。

上面这种断言除了简单之外，是有一个问题，就是当断言被触发时显示出来的错误消息不是很友好。如上图一，只是知道出错了，但是并没有太多有用的信息，比如最好是能显示出x与y的值来，这样好更快的理解为啥出错。后来，支持断言的单元测试框架升级版本出现了，它们提供了一系列的高级”断言“语句，添加了一些更加友好的程序接口，同时还提供比较亲民的错误消息，比如下面的例子使用了两个单独的断言语句。

执行的结果如下图二，你可以看到这个错误结果相对于上面“石器时代”已经包括了不少有用的信息，比如除了知道断言失败外还显示了 期望的值 以及 实际值 。

但是上面这种方式有一个弊端，就是需要大量的预置断言方法（比如判断相等一个方法，判断不相等一个方法等），去支持各种场景。接下来又出现了新的解决方案，其中的明星就是 Hamcrest (其实这个词是使用一种叫做 angram 的文字游戏，即把一个原来单词中的字母顺序改变，这个Hamcrest就是从Matchers的变形)框架。是使用一种 assertThat 组合上 Matcher 来使用。

这个有多个好处，

上面说了这么多，是不是感觉平时经常使用的一个看似简简单单的Assert还有不少的东西可以深挖一下滴。这个只是抛砖引玉，如果大家还有什么点子或建议请使用下面的方式。

---