在脚本设计的过程中，遇到的好处
1.
发挥Postma界面化的优势，快速撰写脚本；
3.
所有的过程代码都会存储到自己的代码仓，留下测试的过程资产，便于版本控制，为持续集成、持续交付等平台提供了无人值守的、按需驱动测试的途径。
工具的便捷性
当我们再次打开Postman会发现，之前的测试脚本被保留下来。可以看到上次我们测试“Battle”系统的脚本还在，可以在回顾一下，同时也可以回忆一下Common类，编写的“Battle”系统脚本，是不是工具更加清晰呢？
这也就是UI操作和代码编写，UI更加清晰直观；代码编写就比较模糊，但是通过代码编写便于维护、合作和保留。所以，两者不分好坏，根据个人喜好来选择。
Postman 设计接口测试直观、快速的优势，将它变成接口测试脚本的初始脚本的编写工具
还是以Battle为例，选择第一个单接口接口测试的脚本，点击【code】；
在弹框中，选择各种技术栈的脚本，我们还是以Python为例，框架依赖于Requests，就可以看到代码了，看到代码是不是感觉编写脚本更加简单了呢？
由此可见，和代码编写相比较的话，Postman来设计接口测试好像更容易一些，，对于我这种小白，更容易掌握一些。
是不是跟上一
篇文章我们编写的第一个单接口测试的脚本此曾相识呢？我们在这基础上，可修改成自己的框架。
接下来我们再看一下第二个单接口
如下
是不是加快了测试脚本的编写了呢，在上面脚本生成的过程中，也很容易再次发现需要封装到框架中的公共方法，这样循环下来，就加快了测试脚本的积累速度，同时也就可以有更多时间用在框架的维护上了。
通过代码的改写和封装，就可以将工具生成的代码完美结合到我们的框架中了，当需要修改已经存储在代码仓库的脚本时，只需 pull 代码仓的代码，就可以看到易读、易维护的测试脚本了。
总结
Postman
工具和你自己的框架相结合的例子，可以通过三步完成工具+框架的组合方式：
1.借助 Postman 这类工具的易学、易操作的特点，将它变成你测试脚本中快速创建的脚本撰写工具；
2.利用工具提供的导出代码功能，将其导出成我们流程化的测试代码；
3.通过我们自己的框架，改写我们通过工具导出的脚本。
