为什么要拓展接口测试能力
上一篇文章 测试那些事儿（十）- 接口测试（上） 我们讲了什么是接口测试能力及如何锻炼自己获得这些能力，今天我们来讲下如何利用学会的接口测试能力继续拓展，让它的功效发挥到最大。
提前声明一下，和上期一样，我们还是不讲工具。做接口测试的工具有很多，Jmeter、Postman什么的比比皆是，选择什么来进行接口测试根据每个人和每个公司的口味而不同。
有同学会问了，接口测试能力功效提升到最大是什么意思？就两个字：提效。具备了接口测试的能力，意味着来了需求后你能够进行业务级的接口测试，但是在一次一次的接口BUG修改后，你需要不停的重复验证；而且，如果本次需求对之前的接口有影响，你还不得不找到之前的接口再执行一遍。长此以往，人不累死才怪。说到这里，大家肯定已经有了答案 - 做自动化啊！
没错，小编团队也已经有了一套成熟的接口自动化体系，但是本期的目的不是来宣扬它的，而是声明创造和使用它的目的。在我看过的无数简历中，都写着“使用python搭建接口自动化测试框架”等等描述，但是面试的时候一问，不是接口测试能力偏弱，就是开发的框架太过简单，根本无法进行深入的接口测试。
为什么？
我想这个是和现在测试行业内的一些现象有关系，如：
- 招聘JD和薪资上轻手工重自动化
- 有编程经验敲门砖会比较硬
这些其实只是表象，最终公司要的一定是具备真才实学的人，要尽量避免只会皮毛，不明就里。
在我看来，手工测试和自动化测试的主要区别在于效率，但核心目的相同，都是保证系统的正确性和稳定性。我在带领团队、培养人的过程中深刻的体会到，一个能够把功能手工测试（用例设计、评审、测试、复盘）做到优秀闭环的测试人，很快就能上手接口测试。而一个脱离了功能手工测试的人，往往设计不好接口测试用例！所以，核心还是测试思维&能力的沉淀。在此基础上做的提升，一定要记住自动化不是目的，提效才是。千万不要为了做自动化而去做自动化！
又有同学会问了，做接口自动化测试框架往往需要编程基础，没有代码基础怎么变得优秀？别忘了我之前说的，那是工具的事儿，现在有很多工具都是开源的，做出一款既有UI又有接口测试功能的框架也不是什么难事儿。而且，刚才说的并不是说具有编程能力会怎么怎么样，而是强调不能只关心编程能力而忽略了测试核心能力，否则就本末倒置了。我认为具备基础的编程能力是很有必要的，因为它能帮助你更好的做接口自动化测试。
业务级自动化接口测试需要什么
这里插一嘴，之前分享过如何做性能测试，我认为也属于接口测试提效的一个分支，所以在这里给下链接：测试那些事儿（七）- 性能测试
业务级自动化接口测试要想形成规模，需要几个必备的东西 - 接口请求&返回值验证工具、参数脚本生成器、接口返回值提取器、结果查看器、发送邮件功能、框架、CI等。
接口请求&返回值验证工具
这个是最基础的功能，要做接口测试我们起码要能够发出请求并获取到返回值吧。并且返回值获取后，起码要保证里面的值要能够进行自动断言验证吧。
接口返回值提取器
由于是业务级的接口测试，所以一个接口的返回值中的一个 key-value 往往是下一个或者下几个接口的参数，那我们就需要能够从任意一个接口返回值中随意获取数据的组件， 也就是提取器。
参数脚本生成器
这个用的机会较少，但是会成为能不能自动化接口测试的拦路虎。比如有些接口需要给出当时的时间，不能是一个写死的时间，怎么办？我们就需要通过编写脚本来生成一个参数，调用这个接口时，使用脚本生成为当时的时间即可。
结果查看器
这个主要是调试的时候用，我们需要在调试接口自动化测试用例时不停的观察参数和结果的数据来保证高效的完成用例编写。
发送邮件功能（参考 Python发送邮件的实现）
整个业务功能的接口测试用例写完后，完整执行一遍，光能够在结果查看器上看到结果是不行的，还需要通知到各个干系人，如测试、开发等。所以，要做好邮件通知的功能，做到结果不遗漏。
框架
也就是将上述所有功能都连接起来进行自定义组合的一套系统，包括上面的所有组件功能。
CI（持续集成）
持续集成是最终的提效工具，它可以让每次开发提交完代码后都出发你的相关业务接口测试，做到接口测试的全面覆盖和监控！
举个栗子
还记得在 测试那些事儿（十）- 接口测试（上） 中我们说的购物车功能的接口测试用例吗？简化一点共涉及添加商品到购物车接口、删除购物车中商品接口、修改购物车中商品数量接口、查看购物车列表接口等四个接口，这四个接口可以组合成闭环接口测试用例如下：
- 调用查看购物车列表接口保证购物车中商品为空
- 调用添加商品到购物车接口添加一个商品
- 调用查看购物车列表接口保证购物车中商品已添加
- 调用修改购物车中商品数量接口增加（或减少）商品数量
- 调用查看购物车列表接口保证购物车中商品已修改
- 调用删除购物车中商品接口删除商品
- 调用查看购物车列表接口保证购物车中商品为空
OK，那我们就套用今天讲的这几个做接口自动化的组件来用这个实例走一遍吧～
- 调用查看购物车列表接口保证购物车中商品为空
这一步用到了接口请求&返回值验证工具，需要按照查看购物车列表接口的文档来输入相应的参数来进行接口请求，且在请求得到返回值后能够进行断言，判断出里面的商品列表为空。这一步进行请求时除了要基础的会需要用到鉴权数据，比如用户token。为了得到它，可以在此之前先调用登录接口来获取token，在进行接下来操作。 - 调用添加商品到购物车接口添加一个商品
这一步用到了接口请求&返回值验证工具，调用添加商品到购物车接口时会用到商品id等信息并验证返回值数据正常，这些信息可以保留为参数来做之后接口的接口返回值校验。如果业务系统对商品id做了转化并在返回值中返回，且会在之后接口中用到的话，需要用接口返回值提取器来将这个值存为参数。 - 调用查看购物车列表接口保证购物车中商品已添加
这一步用到了接口请求&返回值验证工具，调用获取列表后拿到返回值来进行对比，用到了上一个接口中记录的参数们，因为我们要看到列表用真实存在了刚刚添加的商品。 - 调用修改购物车中商品数量接口增加（或减少）商品数量
这一步用到了接口请求&返回值验证工具，调用修改购物车中商品数量接口增加（或减少）商品数量，并验证返回值正确。 - 调用查看购物车列表接口保证购物车中商品已修改
这一步用到了接口请求&返回值验证工具，调用获取列表后拿到返回值来进行对比，保证商品数量正确。 - 调用删除购物车中商品接口删除商品
这一步用到了接口请求&返回值验证工具，调用删除购物车中商品接口删除商品，并验证返回值正确。 - 调用查看购物车列表接口保证购物车中商品为空
这一步用到了接口请求&返回值验证工具，调用获取列表后拿到返回值来进行对比，保证购物车为空。
在写这些用例的过程中和最后，我们需要整体运行用例并观察结果查看器看进行用例调试，并保证在运行完用例后可以通过发送邮件功能通知各个干系人。最后使用CI（持续集成）部署我们的用例，实现每次开发提交接口代码修改时即触发我们的用例。
测试人需关注
本章讲了接口测试提效 - 自动化的一些知识和思想。和其他文章不同，也是让很多小伙伴百爪挠心的是，我自始至终没有讲用什么工具，还是那句话 - 用什么实现不是关键，你的测试思想和目的才是！！！ 大家可以去深入的了解下 Postman、Jmeter、Jenkins等工具，也许会有意外的收获。
