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。不过都是付费功能,免费版有次数限制。
2、文档
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校验或者每个字段的描述,以及更多的测试用例代表更多的细节。
3、Mock
当服务器端还没有写好API时,客户端可以根据Examples来生成MockServer。
建议客户端端自己做Mock,与项目集成在一起,纳入版本控制,方便灵活。强烈推荐json-server,简单好用。
4、测试
对于每一个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自动生成数据就好了…
参考:
json-schema.org
tv4Documentaion
chaibdd-API
postmansandboxapireference
6、测试请求参数
一个请求带有若干参数,如GET的querystring(search)以及POST的body,不同的参数会有不同的响应。
假设一个请求不同参数返回的jsonschema完全不同,则可以写成两个Request分开测试。如果返回的jsonschema相同,只是值不同,则需要考虑传递了哪些参数,参数是多少。
一个经典的场景,根据filter来筛选符合条件的列表。拿用户列表举例,伪代码如下:
一个思路是根据请求的参数进行测试,一段重要的snipet是在postman中获取querystring,query是一种PropertyList的数据,定义在postman-collection-PropertyList。如下:
当然以上filter只包含了最简单的场景,其中只涉及到了相等测试。但是有不等以及包含关系呢。
这种请求参数依赖于前后端的协商交流,当然对测试或者一个不知情的开发来说很不友好的。
当然对于后端也是不友好的,因为需要对你传入的每个query来进行处理,而且以后每添加一个筛选字段,都需要手动改一下。
可以由前端自行决定需要筛选的数据,比如使用类似于mongo的检索语法。
graphql是相当酷的,值得尝试一下。
不过这对于测试的开发能力要求也比较高了,测试人员需要解析参数并且测试接口。
7、测试多次请求
当对一个函数进行单元测试时,需要大量的输入以及期望输出,在postman中,可以使用data来模拟多次输入。
data是一种变量,只能在Runner中使用,有必要对每个Folder建立相关的datafile,并且加入版本控制。
using csvan djson files in the postman collection runner
8、集成测试
单个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集成在一起,但是有一点不方便的是,持续集成仅仅可以保存记录,并不能还原记录。
11、对比UI自动化测试
按照我的理解,UI自动化测试目的是用来测试流程是否通畅,比如登陆,注册,退出,如果用例没通过则截屏。但是前端需求的不断变化,加上现在各种前端框架,导致selector不是特别容易获取到且流程容易更改。
而API自动化测试用来测试数据是否正确。而且大部分问题是出在数据问题上,所以API自动化测试性价比比较高一些。
12、总结
1)如何编写测试用例
postman底层使用chai.js的bdd语法作为断言库,另外加了一些特有的语法。
2)如何debug
点击菜单栏View->ShowDevtools(ShowPostmanConsole)可以查看响应,检查输出,不过不能打断点。对于系统的单个请求,可以使用Proxy监听请求进行调试。
3)如何使用js第三方库对请求就行预处理以及后处理
比如:发送请求时,服务器端要求时间为timestmap(unix)的格式,但接口调试时可读性过弱,是否可以使用moment转化时间。
收到响应时,也需要moment对时间进行解析,获得更好的展现形式。或者使用lodash一些函数进行数据的处理。
可以在Tests和Pre-requestScript中编写脚本对请求以及响应做一些处理。但是不能对数据格式化,比如日期。
建议前后端交流日期时使用ISO格式的字符串,前后端都容易解析,并且可读性强。
4)如何管理请求依赖
比如:两个API需要有依赖关系,比如当创建完一个用户后(注册),获取他的个人信息。获取个人信息就需要依赖创建用户这个API,使用Environment Variables可以管理依赖。
5)如何设置统一的请求参数
比如:大部分接口都需要统一的token参数。目前好像没什么办法。
6)如何集成到服务器端项目中
如果系统后续版本没有通过API测试,则保留测试记录是很重要的,版本控制可以得知该时间段内的代码变更。以git为例,需要每次提交后运行测试,并保留测试结果。可以使用npm包newman来集成到项目中。
文章来源:网络 版权归原作者所有
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系小编,我们将立即处理