|
Postman最基本的功能用来重放请求，并且配合良好的response格式化工具。 高级点的用法可以使用Postman生成各个语言的脚本，还可以抓包，认证，传输文件。 仅仅做到这些还不能够满足一个系统的开发，或者说过于琐碎，你仍需要频繁地在开发环境，测试环境，生产环境中来回切换。单一的请求也不够，你需要维护系统所有API的请求，并且每个请求还带有不同的querystring和body。 1、Collection 对服务器端的所有请求按功能或者业务模块进行组织，使用markdown对所有请求和示例添加适当的描述，这时候就用到了Collection。以下是postman的一些术语以及组织请求的建议。 详细参考PostmanSDKConcepts以及creatingcollections。 Collection：对应一个Application，组内各个成员(server,client,QA)共享一个Collection。可以对整个Collection添加测试，文档。对于一开始未在postman组织请求的应用，可以设置Proxy，跑一遍应用，对应用的所有请求进行抓包。 Folder(Item Group)：对应一个模块，或者各层级子路由。如router.use('/users')所有的请求都在一个Folder，可以根据路由互相嵌套Folder。 Request(Item)：对应一个请求，可以添加认证信息。也可以设置代理，进行抓包。详见capturinghttprequests。 Example：对应一个请求不同的参数以及响应，用于MockServer以及文档。 postman可以根据Collection的结构生成文档与MockServer。不过都是付费功能，免费版有次数限制。 postman自动生成文档有助于团队协作，解决了手动写文档，以及更新不及时的重大bug。 对于GET请求，Postman上可以添加对该字段的描述，生成文档。 对于POST以及PUT请求，如果Content-Type是form-data或者x-www-form-urlencoded可以添加描述生成文档。不过如今传递json更方便灵活，所以application/json也会有很多，而且json又是不能添加注释的。如果需要对json添加文档说明的话，可以添加冗余字段_{key}.comment标明注释：
不过这样冗余字段过多，更好的解决方案是在测试中对请求进行json校验，同时充当了一部分文档的功能。毕竟json-schema就是用来描述数据使数据更加可读。 以上说到请求，对于响应的文档，可以json-schema校验或者每个字段的描述，以及更多的测试用例代表更多的细节。 当服务器端还没有写好API时，客户端可以根据Examples来生成MockServer。 建议客户端端自己做Mock，与项目集成在一起，纳入版本控制，方便灵活。强烈推荐json-server，简单好用。 对于每一个Request都需要有测试用例。验证响应是否成功，响应时间是否过长或者响应json的数据类型是否正确。 测试可以使用pm.expect进行BDD测试，风格和chai很像，如果熟悉chai就很容易上手。 postman内置了一些第三方库，如果你更喜欢chai，可以直接使用，也可以使用pm.expect底层使用chai实现，与chaiBDDAPI一致。 postman也有一些http相关的测试API，如statuscode，header,body，并且也提供了一些snippets。
5、Json Schema json-schema可以用来描述json信息，使json更加易读，同时也可以用来校验json的合法性。主流语言都有实现json-schema的库。 建议对所有GET响应进行json-schema校验，一来校验数据，二来也可以作为文档使用，使用tv4校验json。
同样对于请求也可以添加json校验，不过更复杂一些，因为postman没有直接给出获取全部请求参数的api，需要自己解析和计算 如果postman可以根据请求参数的json-schema自动生成数据就好了... 6、测试请求参数 一个请求带有若干参数，如GET的querystring(search)以及POST的body，不同的参数会有不同的响应。 假设一个请求不同参数返回的jsonschema完全不同，则可以写成两个Request分开测试。如果返回的jsonschema相同，只是值不同，则需要考虑传递了哪些参数，参数是多少。 一个经典的场景，根据filter来筛选符合条件的列表。拿用户列表举例，伪代码如下：
一个思路是根据请求的参数进行测试，一段重要的snipet是在postman中获取querystring，query是一种PropertyList的数据，定义在postman-collection-PropertyList。如下：
当然以上filter只包含了最简单的场景，其中只涉及到了相等测试。但是有不等以及包含关系呢。
这种请求参数依赖于前后端的协商交流，当然对测试或者一个不知情的开发来说很不友好的。 当然对于后端也是不友好的，因为需要对你传入的每个query来进行处理，而且以后每添加一个筛选字段，都需要手动改一下。 可以由前端自行决定需要筛选的数据，比如使用类似于mongo的检索语法。 graphql是相当酷的，值得尝试一下。
不过这对于测试的开发能力要求也比较高了，测试人员需要解析参数并且测试接口。 当对一个函数进行单元测试时，需要大量的输入以及期望输出，在postman中，可以使用data来模拟多次输入。 data是一种变量，只能在Runner中使用，有必要对每个Folder建立相关的datafile，并且加入版本控制。 using csvan djson files in the postman collection runner 单个API测试通过后，需要把所有请求集成在一起进行测试。这时候出现了两个问题： 如何确保API依赖 API之间如何传递数据 请求在Collection的顺序就是他们的发起请求的顺序，如果需要强制更改顺序，可以使用setNextRuest() 在postman中有三种作用域的数据，data，environment，global。在请求中用{{}}占位符替代。 environment可以用来更改HOST，避免在url中频繁手动切换本地环境，开发环境和生产环境。另外也可以用来传递数据。 一个常见的场景是项目使用token来保存登录信息，每次请求都需要携带token。可以在登录的测试代码中设置token的环境变量。
9、测试Collection 确保依赖后，可以对Collection新建一个Runner，并且引入一个data文件来测试所有的请求。对局部的Folder也可以使用Runner以及data进行测试。 最新版本的postman已经可以支持，为每个Postman新建变量以及Test 所有的请求都会有一些共同测试，比如测试接口是否响应成功以及以上提到的测试filter。
10、持续集成 当可以测试Collection后，需要对测试加入版本控制，与项目集成在一起，保留测试记录，以便准时定位bug。可以与postman的官方工具newman集成在一起，但是有一点不方便的是，持续集成仅仅可以保存记录，并不能还原记录。 按照我的理解，UI自动化测试目的是用来测试流程是否通畅，比如登陆，注册，退出，如果用例没通过则截屏。但是前端需求的不断变化，加上现在各种前端框架，导致selector不是特别容易获取到且流程容易更改。 而API自动化测试用来测试数据是否正确。而且大部分问题是出在数据问题上，所以API自动化测试性价比比较高一些。 1）如何编写测试用例 postman底层使用[chai.js](http:///api/bdd/)的bdd语法作为断言库，另外加了一些特有的语法。 2）如何debug 点击菜单栏View->ShowDevtools(ShowPostmanConsole)可以查看响应，检查输出，不过不能打断点。对于系统的单个请求，可以使用Proxy监听请求进行调试。 3）如何使用js第三方库对请求就行预处理以及后处理 比如:发送请求时，服务器端要求时间为timestmap(unix)的格式，但接口调试时可读性过弱，是否可以使用moment转化时间。 收到响应时，也需要moment对时间进行解析，获得更好的展现形式。或者使用lodash一些函数进行数据的处理。 可以在Tests和Pre-requestScript中编写脚本对请求以及响应做一些处理。但是不能对数据格式化，比如日期。 4）如何管理请求依赖 比如:两个API需要有依赖关系，比如当创建完一个用户后（注册），获取他的个人信息。获取个人信息就需要依赖创建用户这个API，使用Environment Variables可以管理依赖。 5）如何设置统一的请求参数 比如:大部分接口都需要统一的token参数。目前好像没什么办法。 6）如何集成到服务器端项目中 如果系统后续版本没有通过API测试，则保留测试记录是很重要的，版本控制可以得知该时间段内的代码变更。以git为例，需要每次提交后运行测试，并保留测试结果。可以使用npm包newman来集成到项目中。 文章来源：网络 版权归原作者所有 上文内容不用于商业目的，如涉及知识产权问题，请权利人联系小编，我们将立即处理 |
|
|
