案例：如何把流程化的测试脚本抽象为测试框架？
为什么要开发自己的测试框架？
我们说到了用 Postman 来完成接口测试，但随着你的接口测试项目逐渐增加，你会发现越来越难以管理它的脚本，虽然测试工具导出的测试脚本也可以存放到代码仓库，但是，如果只是通过代码来查看是很难看懂的，你必须用原来的测试工具打开，才能更容易看懂原来的脚本做了什么样的操作。
搭建测试框架，不要纠结于技术选型在
做接口测试脚本开发的技术选型上，我更建议你根据自己的技术实力和技术功底来选择，而不要以开发工程师的技术栈来选择。
我们作为测试工程师，无论是使用自动化的接口测试，还是界面的手工测试，第一目标都是保障交付项目的质量，那些业务侧的表现，在大多数情况下不是我们关心的重点
用你的框架完成多接口测试
测试框架的形成是在撰写大量测试脚本的过程中不断抽象封装出来的，然后，再用这个不断完善的框架，改写原有的测试脚本。循环往复这个过程，你就会慢慢获得一个独一无二的、又完全适合你工作的接口测试框架。
其实到这里，我们上面说的只能算是一个调试代码，还不能算是一个测试框架。上面这些代码所有的返回值都打印到控制台后，为了完成接口测试，你需要时时刻刻看着控制台，这还不能算是自动化，只能说是一个辅助小工具。
在这里，你应该让全部测试结果都存储到测试报告里面，同时通过一个测试驱动框架来完成各个模块的驱动，这也是为什么你在学习任何一种框架的时候，总会遇见类似 Java 的 JUnit、Python 的 Unittest 的原因，因此，上面的 Common 类还需要和 Python 的 unittest 一起使用，才算是一个完美的测试框架。
总结
总结今天，我们一起学习了一个测试框架的诞生过程。测试框架就是在你测试脚本中不断抽象和封装得来的。今天我们课程的内容充斥着各种代码，如果你的代码基础稍微比较薄弱，并没有完全记住上面的内容，那么我希望你记住从测试脚本到测试框架的转化过程：
- 不断撰写测试脚本，所有的抽象和封装都是站在已有的测试脚本基础之上的；2. 多观察已经写好的测试脚本，找出其中的重叠部分，最后完成封装；
- 以上两步是一个不断循环又循序渐进的过程，你要在你的工作中始终保持思考和警惕，发现重复马上进行框架封装。
最后我想和你强调的是，测试框架的封装和抽象过程并不是一蹴而就的，它是靠一点一点的积累得来的，因此，你要通过自己的实践，慢慢积累和完善你的测试框架，而不要妄想一次就能有一个完善的测试框架。我相信，当你通过写脚本完成整个项目的接口测试后，你一定会得到一个完美的测试框架。
测试框架如何才能支持RESTful风格的接口？
RESTful 风格接口关我什么事？
它主要就是一组设计原则和约束条件，本质上就是让消费者依据 URI 就可以找到资源，并通过简单的服务输入输出完成服务的交互。
它所约束的每一个 URI，都是独一无二的一个资源，通过 HTTP 的方法进行资源操作，实现表现层的状态转化。这就和螺丝刀刀头一样，待解决的问题就像螺丝，每一个接口只面向一种特定的资源，而不需要关心其他接口的处理方式，这样，你就能够一目了然地知道，该用哪种螺丝刀头拧哪种螺丝了，这就降低了接口开发的复杂度。
软件开发人员只要遵循 RESTful 的实践标准，按照一定的内部定义开发外接口，就会形成类似螺丝刀刀头一样轻便的接口，对外提供服务。现在的很多项目，无论是服务端和服务端的调用，还是前端和服务端的调用，都采用了这一种方式来设计接口。
让你的框架可以测试一个 RESTful 风格接口
现在，你知道 RESTful 接口和你的接口测试有很大关系了，那么，RESTful 接口的测试和原始的 HTTP 协议接口的测试，又有什么区别呢？
这里面有两部分需要你特别关注：数据交换的承载方式和操作方式。
我先说说数据交换的承载方式，RESTful 风格的接口主要是以 JSON 格式来进行数据交换，如果你还记得我之前提过的“Battle”这个系统（你可以回到03中查看它），那么你一定在它的 Readme.md 中，看到了 Request 和 Response 对数据部分的一些定义，那就是 JSON。虽然“战场”不能算是一个严格的 RESTful 接口的系统，但是，在数据交接的承载方式上，它模仿了 RESTful 的样子。
另外一个部分是操作方式，在“战场”系统中，我们用了 HTTP 协议的 Get 和 Post，其实 HTTP 协议有很多方法，但是我们仅仅用了这两种，而 RESTful 的规定，使 HTTP 的很多方法都被利用到了，比如说，Get 方法用来获取资源，Post 方法用来新建资源（或者更新资源）；再比如说，Put 方法用来更新资源、Delete 方法用来删除资源等等。
总结
在文中我讲了很多内容，但是完成 RESTful 风格接口测试，主要是通过两步操作，来为你的测试框架添加对应接口的测试能力的：
- 借助外力。目前网上已经有很多成熟的、各式各样的支持库，你要尽量拿来为己所用，而不要从零建设，这样，既弥补了我们开发能力不强的短板，也能提高我们的研发效率。
- 自己封装。你要注意的是，自己封装和借助外力并不互相冲突，你要借助外力，然后将它封装到你自己的框架中，这是一个借力打力的好方法。
接口测试平台：工具和框架不可以兼容？
工具的便捷性与框架的灵活性可以兼得
在前面我先讲了 Postman 这款非常好用的 HTTP 测试工具，后来又讲了怎么自己动手封装接口测试框架，它们各有特点，比如工具有便捷性，框架有灵活性，这无疑是两条都可以通向罗马的路，是两种都可以完成接口测试工作的方法，那学会一个不就可以了，为什么两个都要学会呢？
而且工具和框架，这两件事看起来互不相干，甚至有些互相排斥，那么这两种接口测试技术手段能相互支持，能融合到一起吗？下面我就来回答这个问题。
其实，工具和框架，这两条通向罗马的路可以并成一条快速通道，让你大踏步进军罗马。所以我既建议你要掌握一款好用的工具比如 Postman，也建议你用自己的技术沉淀出自己的框架，如果你能正确地混合使用它们，实质上就可以搭建起一个接口测试平台，帮你更快速地完成测试任务。
在脚本的设计过程中，这样做有两个好处。一是能充分发挥 Postman 界面化的优势，快速完成大量的脚本撰写工作；二是通过你自己的框架完成测试脚本的执行，所有的过程代码都会存储到你自己的代码仓，这样，既可以留下测试的过程资产，也便于版本控制，这也为持续集成、持续交付等平台提供了无人值守的、按需驱动测试的途径
工具的便捷性可得
这也是 UI 操作和代码操作的区别之一，UI 操作更加直观，可以在你的脑海里留下更深刻的印象；而代码操作给人留下的印象就比较模糊，但是，通过用代码写脚本来完成接口测试，比较便于维护、团队合作以及留存。
总结
我今天以 Postman 工具和你自己的框架相结合的例子，告诉你如何建立一个你自己的测试平台，你可以通过三步完成工具加框架的组合方式：
- 借助 Postman 这类工具的易学、易操作的特点，将它变成你测试脚本中快速创建的脚本撰写工具；
- 利用工具提供的导出代码功能，将其导出成我们流程化的测试代码；
- 通过我们自己的框架，改写我们通过工具导出的脚本。
最后，你的测试脚本可以存入代码仓中为持续集成平台提供持续验证，这就完成了一套简单又灵活的接口测试平台的建设。实际上，在本节课中，我更希望帮你建立一种解决问题思路，测试工程师的技术普遍会稍微弱于开发工程师，你要善于利用各种技术手段来帮助自己解决问题。
