Postman自动化接口测试本文面向已经掌握Postman基本用法，即对接口相关概念有一定了解，并且已经可以使用Postman模拟请求操作的读者。当前环境：Window7-64位Postman版本（免费版）：ChromeAppv5.5.3不同版本的页面UI和部分功能位置会略有不同，但影响不大。我们先想一想，如果我们需要达到自动化接口测试的效果，我们还需要在基本的模拟请求上做些什么呢？我大致总结了以下三个问题（欢迎更多补充和建议）：如何判断接口请求是否成功，如何对接口进行批处理，定时测试如何处理依赖接口问题（例如放置的接口ordermustrequireloginfirst)所以，继续主要分为3个部分进行介绍，分别解决这3个问题。接口结果的判断首先，既然是自动化测试，我们肯定需要一个工具（Postman）或者代码来帮助我们直接判断结果是否符合预期。那么在接口测试中，一般有两种思路：判断请求返回的代码是否符合预期，判断请求返回的内容是否包含预期的内容（关键字）。接下来我们看看如何使用Postman来解决以上问题：functionPostman中的相关函数非常显眼。Tests功能的使用需要我们有一定的编程语言基础。当前支持的脚本语言是JavaScript。但更好的一点是，我们不需要考虑上下文和运行环境，也就是说，我们只需要在这里完成结果逻辑判断的代码块。并且Postman还在Tests面板右侧的SNIPPETS功能区中为我们提供了一些常用的代码模板，所以如果你对JavaScript不太了解也不是什么大问题。下面将详细介绍代码编写相关的内容。脚本相关首先看上图的代码部分，我们可以发现三个变量（responseCode、responseBody和tests）（可以直接使用）：responseCode：包含请求返回的状态信息（如：code）responseBody：接口请求返回的数据Content(typeisstring)tests：以键值对的形式，用来表示我们的测试结果是否成功，最终显示在TestResults中。key:(eg:code200)我们可以用它来作为结果值的描述：它的值为Boolean，ture表示测试通过，false表示测试失败。所以上面的代码应该不难理解，有了返回的结果数据和判断结果成功与否的方式，那我们的“接口结果判断”问题就基本解决了。另外还有几个比较常用的：responseTime:请求的长度setGlobalVariable("variable_key","variable_value");代码模板SNIPPETS功能区Postman提供的代码模板已经可以解决大部分情况。这里有几个和结果判断相关的解释：Statuscode:Codeis200//根据返回的Code判断请求状态tests["Statuscodeis200"]=responseCode.code===200;Responsebody:Containsstring//判断返回内容中是否有“关键词”。（tests的key可以修改，不再强调）tests["Bodymatchesstring"]=responseBody.has("这个可以改成你要判断的关键词内容");//如上：//判断结果中是否存在access_token关键字tests["hasaccess_token"]=responseBody.has("access_token");Responsebody:isequaltostring//判断返回的内容是否与预期的正好相等。tests["Bodyiscorrect"]=responseBody==="Youcanchangeittoyourexpectedcontenthere";Responsebody:JSONvaluecheck//上面说了responseBody是string类型，支持转换为Json格式varjsonData=JSON.parse(responseBody);tests["Yourtestname"]=jsonData.value===100;Responsetimeislessthan200ms//判断请求时间是否小于200ms，具体时间根据自定义情况测试["响应时间小于200ms"]=responseTime<200;上面的介绍基本上已经足够完成单个接口的测试了，但是我们知道，如果没有批处理和定时任务，那么这些就没有意义了，继续...collection(batch)test如果要进行批处理测试和接口的管理，那么我们需要把所有要测试的接口保存在同一个集合（Collections）中，可以想到保存在同一个文件夹中。先看Postman中的操作步骤：通过以上步骤，我们得到了一组待测试的接口。为了简化情况，这里每个接口成功的条件是判断code是否为200：tests["Statuscodeis200"]=responseCode.code===200;批量执行以上准备好后，我们就可以开始批量运行界面进行测试了：点击运行后，会打开一个新的页面：环境：用于切换界面运行我这里不关心环境，还有后面会讲到Iteration：它是用来设置界面运行的总次数。Delay：设置每个运行界面之间的时间间隔，以毫秒为单位。数据文件：上传测试数据文件的参数数据（下面单独说明）我们已经了解了如何让多个接口运行多次，但是现在有一个问题。按照现在的步骤，每次运行界面的参数变化都是一样的，所以就算我们运行100次或者1000次，也没有多大意义。推荐一个SpringBoot基础教程和实例：https://github.com/javastacks...看一下我们现在写的一个登录函数的界面：使用变量登录。帐号和密码参数是硬编码的，也就是说不管我们执行多少次，我们都是用这个帐号来测试的。那么如果要测试账号密码参数使用其他值是否有异常怎么办呢？（如果你想每次都手动更改，可以跳过这部分/手动滑稽）这里我们简单说一下如何在Postman中使用“变量”，如下图所示：引用变量的语法：{{变量名}}，图中可以看出，我们将帐号和密码字段的参数值设置为变量：{{username}}，{{password}}。修改后直接点击Run(Send)当然是不行的，因为这两个变量还没有赋值，但是我们可以在Pre-requestScript面板中进行赋值操作：Pre-requestScriptPre-requestScript类似于Tests，区别在于：Pre-requestScript中的脚本是在执行请求前运行的，而Tests中的脚本是在请求完成后执行的。因此，我们可以在Pre-requestScript功能区使用脚本为以上两个变量赋值，比如//设置全局变量postman.setGlobalVariable("username","test1");postman.setGlobalVariable("密码","123456");但是使用Pre-requestScript进行赋值操作还是解决不了我们的问题，因为按照这种写法，无论运行多少次，它仍然是使用固定（硬编码）的数据进行测试。当然，既然是脚本语言，会有更灵活的用法，这里就不展开讨论了。测试数据集接下来说说DataFile。该选项在运行集合之前用于上传测试数据（文件）以分配给相应的变量。我们以CSV格式的测试数据为例：username,passwordtest1,123456test2,222222test3,123456test4,444444数据格式类似于表格。正确的数据），我们保存一个文件，内容就是上面的示例数据，后缀为.csv，再次开始测试，看看效果。我们选择运行次数为4（对应4组测试数据），并选择对应的CSV文件运行，可以看到我们的结果和我们预期的一样。接口Request运行的结果是两次成功两次失败，即每次运行分配不同的账号密码测试数据（在最新的桌面客户端版本中，可以看到每次具体的请求情况，这里不再赘述）。如果使用Json文件，格式如下：[{"username":"test1","password":"123456"},{"username":"test2","password":"222222"},{"username":"test3","password":"123456"},{"username":"test4","password":"444444"}]定时任务Postman提供了一个Monitors（监控）功能，它支持我们提交一个测试任务按照设定的定时器运行，比如每小时测试一次。具体操作如下：请求依赖问题接口结果判断和采集批量测试结束后，我们来看更复杂的情况，即依赖请求问题，比如我们的购物订单接口需要你先登录你可以访问它。但是大部分的依赖问题其实是接口之间的数据传递问题。比如调用登录接口后，返回一个标识，假设是token。那么我们在请求下单接口的时候，只需要在请求的时候携带token参数即可。因此，问题就变成了：保证接口调用的顺序，将接口A返回的数据传递给后续接口B、C、D的。或者以我们上面创建的接口集合为例。如果大家关注我们批量测试的结果，就会发现接口的执行顺序其实是按照这里目录中的顺序（从上到下），即：Request1->Request2->Request3。这里的接口名称可能有点误导，所以我想再次强调一下：它是按照目录中从上到下的顺序执行的（与字典排序无关）。那么有了这个默认的执行顺序，那么我们就可以把需要先执行的界面放在前面就可以了，比如把“登录界面”放在前面。自定义执行顺序当然，如果只有一个默认的执行顺序，通常不能满足我们复杂的业务需求，所以Postman为我们提供了一个函数：postman.setNextRequest("填写你要跳转的界面名称"),支持我们跳转到指定界面继续执行。例如：运行Request1接口成功后，我们不需要再运行Request2，直接跳转到Request3。然后我可以在Request1接口的Tests功能区执行跳转代码，比如：这里有几点需要注意：postman.setNextRequest()只有在运行采集测试的时候才会生效，也就是说，当我们单独运行(Send)接口Request1，功能不起作用。当我们从Request1->Request3运行采集测试成功后，如果Request3后面有接口，那么后面的接口会按照默认的顺序继续执行，即图中的接口Request4仍然会被执行。指定的跳转接口必须属于同一个集合。无论setNextRequest()函数在Tests脚本中的什么地方被调用，它实际上只是在当前脚本的末尾执行。比如我们把图中的第二行和第一行互调，运行跳转函数后仍然会执行第二行代码。因此，使用setNextRequest()函数，我们可以根据条件跳过不需要的接口，或者创建自己的逻辑测试。数据传输说数据传输之前，先说说Postman中全局变量的使用和环境切换。全局变量全局变量的概念其实我们在上面讲Pre-requestScript的时候简单提过，也就是说我们可以通过脚本代码来设置全局变量。运行后，用户名和密码变量会被成功保存，然后我们就可以通过变量引用语法在任何界面中使用它们，例如：{{username}}。另外，Postman不仅支持代码设置全局变量的方式，还支持可视化操作：进入相应界面后，可以直接管理：多环境区分和切换通常我们的界面分为测试版和在线版本（或更多），它们的区别可能只是ULR，那么全局变量不适合解决这个问题。参数创建大家可能已经注意到，在上图中，我创建了几个不同环境的参数“集合”。再看一下：我在每个环境中都创建了一个host参数，比如：当然我们的Environment参数也可以通过脚本来设置，作用是：//注意，这个参数只添加到“参数集”中您当前选择的环境postman.setEnvironmentVariable("variable_key","variable_value");使用with切换环境“参数集”中参数的用法与全局变量相同，如图{{host}}，不同环境的切换如下图所示：解决依赖问题掌握了以上初步知识后，我们就开始看看如何使用PostmanResolve接口测试存在依赖的地方。假设我们的接口Request1是登录接口的场景，登录成功会返回一个access_token字段作为标识（已实现）。那么假设接口Request3为下单接口，需要携带login返回的access_token才能正常访问。思路是保证Request1先于Request3执行，将Request1返回的access_token值添加到环境变量“parameterset”中。Request3在请求时引用access_token的值，将返回值存放在“全局变量”或“环境变量”中。这取决于具体的业务情况。本例中access_token的值与环境有关，所以这里选择使用环境变量settostore。Postman中的操作1.Request1接口已经保证在我们的目录中先执行2.Request1中Tests的代码：if(responseCode.code===200&&responseBody.has("access_token")){//Ifcode为200，返回数据中有access_token关键字，则认为登录成功tests["login"]=true;//将返回的内容转为json格式，并获取access_token内容，添加到环境变量中varjsonData=JSON.parse(responseBody);//access_token的取值取决于具体的json数据结构postman.setEnvironmentVariable("token",jsonData.result.access_token);//跳转到Request3接口postman.setNextRequest("Request3")}else{tests["login"]=false;//如果登录失败，可以选择失败后跳转到对应的处理界面进行测试//postman.setNextRequest("OtherRequest")}3.接口中使用Request3变量token：我把token放在这里的header信息，具体用法看接口参数规则。运行runcollection测试，结果符合我们的预期，Request1和Request3通过测试，Request2被跳过，Request4仍然执行。
