先收藏，虫师作品值得学习

博客园跟了好久，终于来这了

写平台一部分是给这些人用的：
那些代码都看不懂，一写接口测试用例就不想写，说自己不会代码觉得麻烦，还不想学习
就想别人把饭盛好喂到嘴里的那些人

感觉第二版才是适合复杂逻辑使用的. 第三版看描述就是第一版的界面优化版.

虫师发帖，先点赞再说

原来群主在 klook，之前买悉尼动物园门票还用过 klook

偶像虫师的帖子，点赞

一是领导要求为了面子工程，二时服务那些基本没啥代码基础，只懂业务的测试人员，三是测试到了一定年限，总的弄点高大上不同于普通测试工作的东西出来吧。

终于等到你！

赞一个

我怼过做填 “写表格” 自动化工具的人，鼓励大家通过代码做自动化，写代码多自由啊！可是，做工具和平台的人一定要假定一批，他们不懂代码，而且还必须要让他们做自动化的测试。然后，把自己放在一个 框架/平台 的制造者。实际情况是：

• 谁愿意做平台的制造者？

• 谁只愿意做平台的使用者？

我想稍微有点追求的测试都会选择前者吧！

之前我也想过此类问题，框架还是平台？

其实没有硬性的选择，要看面向的对象：
假如是土豪公司，招各个都是有技术傍身的人，用框架写代码，各种测试场景想怎么飞怎么飞；
如果是穷公司，考虑各种人力成本，只有极少数会点代码，其他全是手工测试，难道还指望那几个人敲代码去维护庞大的用例场景？
血的教训告诉自己，少数人牛逼没有用，没有一个团队的支持，再怎么厉害也是白费

虫师出品，必属精品

如果是把你空降到一个功能测试为主的团队。 你其实可以选择做一个平台去解决他们的问题，也可以选择找出几个懂些代码来培养写框架来结束。

首先，我不认为接口是适合每个测试的，或者每个测试都必须要参与到接口测试中的，我觉得不懂一些接口实现逻辑的话也 很难设计好接口测试用例 。

做平台面临的挑战更多，如果做的没有 postman 强大，测试不会用。如果做的特别强大，那么一定很难用！哈哈！

当然，每个公司的情况是不一样！

等你发现测试框架无法满足你的时候，你就会想写一个工具来满足你的要求了，写完工具会想何不共享一下？这就做成了一个平台。

白嫖怪，已就位。坐等各位大佬分享

大佬不可能不知道什么叫开源吧 重复造轮子费时费力。现在论坛里谁分享个啥子平台出来，下面评论多是各种反应跟自己的好像差不多，大同小异的。结果导向的事情大家为什么要走那么多弯路呢

API 方面:

• 1.要有单个 API 所有请求数据记录
• 2.详细的请求和返回数据
• 3.请求之前的数据加密和签名
• 4.请求之后的清理
• 5.请求结果抽取出来,放到下个 API 中使用
• 6.多个 API 联合调试
• 7.多个 API 组装成用例
• 8.API 的版本状态管理 (成功,失败,未调试之类)
• 9.多种断言模式

你想法刚好相反，框架是最灵活的，在框架的基础上扩展是容易，如果框架都无法实现，工具和平台就更不能。工具和平台解决的是 不让你写代码做接口测试 ！

虫师的文章自带 BGM，欢迎！

原来大神也是在造轮子，真理解不了测试平台的价值在哪里，又有多少人愿意在 web 上去录测试用例， IDE 写测试用例代码更快
现在的现象是 很多人都想着去做测试平台什么的，到底团队需要什么，应该做成什么样子，能不能提高效率 这些都不考虑。很多做测试平台仅仅是为了学习

一开始我也想着用框架,有参考过你那一套.《web 接口开发与自动化测试》
最后了用 FasterRunner.基础 HttpRunner 的 web 平台.
由于 HttpRunner 有 debugtalk 这个神器的存在,让平台灵活了很多.
主要是为了满足:

• 和公司 API 平台对接,实现自动录入 API.
• 开发调试 API
• 多人同时使用
• 面子工程,老大想弄平台

没有动手的人永远在找缺点，你说它无厘头也好，骗骗没动手的人总是能有奇效，并且引发舆论也有独树一帜的快感。
真真实实动手完成了的人，又确实解决了团队的诸多问题，可能不完美，但是全方位收获颇多。
回头看看那些打嘴炮的人，还是保持安静偷偷发育比较好。

虫师大佬难得发一个帖子，撒花。不过其实我和上面很多同学是一样的看法，现在大部分的接口测试平台，最大的用处就是满足自己装逼的需求，实际效果其实并不好。如果要达成所谓<不让你写代码做接口测试>这个需求，做成一键式执行，所有内容都有测开搭好，功能测试只需要上平台选择要测试的内容（包括测试哪些接口，使用哪些 body，而这些都已经预设好了），然后开始测试，这样才算是比较接近这个需求。

呵呵了。你能说一个框架是你心目中完美的框架吗，它就没有缺点吗？
“如果框架都无法实现，工具和平台就更不能。” 为什么我不能改框架的源码来实现自己的需求呢？为什么我不能组合多个框架的优点来达到自己的目的呢？
框架总有缺点，而我做工具或者平台，就是组合各个框架的优点，让其合并在一起。相信各位做平台的也是这个目的。
“工具和平台解决的是 不让你写代码做接口测试 ！” 就比如接口测试的断言部分吧，postman 都是写脚本的形式来断言的，用我截图给你吗？是叫 Javascript ，

怎么了，你要告诉我 postman 不行，它不是一个成功的工具，是因为它让我写代码了，让我写了代码才能做接口测试了。那你的工具超过 postman 了吗？
不是说想怼你，你怼别人的时候最好想想自己说的是啥，你到底想清楚问题没有。

请教个问题，断言怎么做到灵活断言呢

我个人是比较喜欢用框架来实现测试用例的开发调试和运行，平台只做用例展示和结果展示。

最近在做框架的另一种尝试，灵感来自于 rest-assured，充分复用到 IDE 的语法提示和自动补全。
大致是这样的：

支持，实现真正的自动化，平台的角色比重 30%，自动化框架优化、用例编写占到 70%
平台仅用于驱动和数据展示即可，重点还是用例规范和用例编写能力

这样有一个问题，你把每个方法都返回整个对象正常情况下是很畅快的。
但是遇到一些特殊的验证，比如我需要对返回的 body 做一定的处理再进行 equals 的断言，这样就需要一个中间变量来转移。
或者你再增加一种 assert 的方法。
使用中间变量会打破你这种链式的书写方式，让代码变得非常凌乱。增加一种 assert 到后期你会有巨多的 assert 方法，语法提示选择的时候也是很灾难的。
另外，为了维持这种链式对象，你每个方法返回都受到了限制，扩展起来是不可能的。
就等同于一个 json 对象。

围观虫师

链式不是绝对的。采用链式能覆盖绝大多数场景，对于一些特殊场景，使用中间变量也可以接受的。

可以看看 rest-assured 。链式调用的校验阶段返回的对象，除了可以通过链式调用做断言，也可以取出任意返回值。

框架能满足 80% 场景的需求，剩余 20% 通过高成本一点的手段能满足，我觉得这就是一个挺不错的框架了。

PS：我司内部目前基于 rest-assured 推广接口测试已有超过 1 年时间，但实践中大家对于全链式调用的接受度不是太高，因为实际用例中 request 部分大多差异不大，但 response 校验部分差异较大。而全链式调用从头写到尾，会导致 request 部分重复度高。

目前优化后的用法是：
1、 request 部分封装成函数，返回一个 rest-assured 的可链式写断言或提取表达式的对象，供用例进一步使用。
2、一些通用类参数或统一加解密，做到 filter 中（类似于 spring 的 aop ），用例不需要为此额外写任何东西。

框架和平台，我觉得本身特点和定位不一样，各有优势，但两者可以并存共赢。debugtalk 提出的框架来实现测试用例的开发调试和运行，平台只做用例展示和结果展示，也是挺好的结合方式。

框架/工具：
优点：灵活度高、可以套各类设计模式、idea 自动生成 + 断点调试等，简单的说就是写用例很爽。
缺点：要有编程基础，要装运行环境。简单的说就是执行测试不那么爽。

平台：
优点：不用本地装任何东西，有个浏览器就行。非常便于推广到非测试团队使用（如开发点一下就执行测试），也便于数据收集统计。简单的说就是执行测试很爽。
缺点：GUI 交互的灵活度会低一些，业务复杂度高的用例写起来可能不那么方便。如果采用写代码类的方式，因为缺少断点调试和自动生成，效率也会降低。简单的说要做到写各类用例也爽不容易。不过如果是轻量级的接口测试（录制或导入接口文档生成 request ，校验主要验证返回码 + 少量返回值，涉及多接口调用的链路不多），这个问题估计也不大，甚至使用上学习成本比写代码低不少。

个人觉得这个事情没有绝对的对错，要根据实际情况来看。适合当前公司团队的才是最好的。至于那些说做平台只是为了装 B 的，说明他们在了解团队实际需求上没做好，只是按自己想法去做，而不是按大家的想法去做。这类情况可以参考的一种解决方法，就是让测试开发开始设计平台前，先到业务测试组轮岗 1-2 个月，熟悉业务测试的实际情况，以后也好相互交流沟通。

” 框架能满足 80% 场景的需求，剩余 20% 通过高成本一点的手段能满足，我觉得这就是一个挺不错的框架了。“
个人觉得这点平台也能做到

是的。个人觉得不用纠结用是框架还是平台，能简化这 80% 的场景的工作量，就产生价值了。

框架和平台各有好处，框架灵活便于调试，平台方便推广，数据存储和展示，直观方便，每个工具的受众不一样。
站在测试人员的角度上肯定都愿意做框架，因为可以从中学习写代码，提升自身技术能力；
但作为公司的角度，需要的是快速产出，如果每个测试都去学习写代码做自动化，那么公司的成本就变高了；平台的一个优点就是方便
功能测试人员去低门槛的录入接口自动化用例，为啥不让自动化测试人员或测试开发来编写呢？（功能测试人员对业务更为熟悉）。
如果公司还没有发展到需要平台的支撑，只需要简单的回归一下，那么框架的接口自动化更为方便，所以还是要看公司的取舍，
并不是谁对谁错。

是的，我现在也面临这问题

为了 kpi

本人经验，平台好处两点，
一在框架中写脚本除了测试数据外其他基本是重复且无提升水平代码（框架封装的够好）；
二是有些测试人员确实代码能力不够，自己写脚本容易出各种问题，平台免去了这些错误的重复发生。

摩拜虫师大佬

哈哈哈哈，测试平台仅供测试交流学习，如果不付出最基础的测试平台开发的辛苦的 “邯郸学步”，那么又如能能体会一个高可用的平台诞生到底需要些什么呢？写多了做多了自然就懂了，以前做的事那些对，那些错。那些功能可高复用率。

写一个 jar 包工具，当初一开始只有简单 GUI 界面后面慢慢拓展为支持命令行、Java 调用、Python 调用，曾经走过才能体会这过程以后的路上会走的更好。学习需要一个高度专注。

一个测试小白的个人感言

GUI 界面只是方便小白使用加密解密数据，而后面拓展给愿意折腾的人去做扩展。最后的结果：手动操作也可，要自己去调框架写也行。Jmeter、Java、Python 随意基础包的方法已封装好并维护了一套秘钥库。

你都没理解虫师说的话，虫师说的框架是 unittest,pytest 之类的，当然你技术牛逼的话，可以进行扩展，比如 httprunner 不就继承 Requests 的全部特性。号称自动化最佳实践。“不让你写代码做接口测试 ！” 这句话的意思是工具和平台几乎不需要写代码，对测试人员编码能力要求低。 你说 postman 写个 js 断言，是写代码，而虫师说的写代码，更多是指编码，编程。是有灵魂的。而 postman 断言写的几行代码，基本上写好一个，其他就可以复用。平台和工具还是有区别的，工具无法数据可视化和统一管理，对于领导想看测试质量数据的话，平台可以做到集成 UI，接口，性能，安全，代码质量扫描等等这些功能模块上去，前提是你技术足够强大把它做好。也可以说是为了装 13，比如有些测试部领导要向老总展示自己部门是一个有技术和实力的部门，是有存在的价值，这个时候数据才是唯一能证明的东西，而数据可视化就得依赖平台了。不可能去手工统计测试数据。一个测试部少则几十个测试，多则 100 来个测试，甚至更多，使用 postman，你们领导怎么向领导汇报测试管理数据？ 手工统计？使用 postman，接口预警，消息推送，报告自动化发送，bug 自动提交，代码扫描，质量管理等等，你能做么？

还有在这挖坟的……我感觉你不是想怼我，而是自己对这些问题自己没有啥解决方案或者是知难而退了，借着回复我吐槽一下。
其实时代已经发展了……
了解一下阿里云效平台（测试管理部分，流水线部分）吧，你的想做的这些问题已经解决的差不多了，比如代码扫描，质量管理，报告自动化发送，消息推送，接口预警（卡点）都可以。bug 自动提交这东西不好做哈，毕竟还是需要人工确认一下，但是设置一个卡点是可以的。而这些，我认为云效平台结合 postman 都是可以做的……。而数据的可视化，是云效平台的卖点之一了。
可能你对测试要开发的平台没有太深入的思考吧，有些重要的平台是需要你说的 “有灵魂的编码” 的，不过你的举例不太好（具体啥平台我就不提了……不想替你思考）。
接口自动化测试平台就别再吭哧吭哧的自己研发了哈，比如一些这个社区内比较知名的开源的，好几个了吧，什么 httprunnerManager，Hitchhiker 之类的，都已经停止更新了哈，风向标比较明显。用些好用的开源的就行了（httprunner 是可用的我是支持的！）。

不经常逛 testerhome。

如果框架都无法实现，工具和平台就更不能。

我来解释一下：

• 框架

我这里说的框架是代码框架，像 django、spring 这些 web 框架，本质上提供的给你的还是类方法，让你去使用和扩展，你可以用，可以只用一点，也可以自己灵活的实现。所以，我觉得没有什么是代码解决不了的。

• 工具

我当然 知道，postman 可以用 js 写扩展，我也知道 robot framework 可以自己封装 系统关键字，我更知道 httpRunner 可以在 debugtalk.py 自己封装函数。JMeter 也是可以用 Java 做扩展的。

• 平台

我自己做过专职平台开发，当然也知道平台也代码开发的，有啥功能不能做？

可以问题是，我都用你的工具和平台去写代码了，说明你的工具和平台需要有代码基础的人才能用的顺手，为啥不能更加舒服高效的直接用代码解决问题？

我的大部分观点，只是站在测试新手这边，鼓励大家写代码，多用框架这些工具，多了解一些底层的东西，写代码更加自由，更加灵活。

而站在那些已经 已经跨过了新手阶段的，专职测试开发，测试 Leader，公司高层，现成的工具不香？我们做的平台不香？ 有需求你提，我给你加！我理解，平台更好的衡量产出，可以做到更多维度的统计。 这些都是代码框架不具备的。

可惜，新手看到的只是你这个报告挺好看的，我去学些。这也是为什么HTMLTestRunner 报告被定制了 N 多个版本， 去用 pytest 只是因为 allure 报告好看。

不知所云，前后矛盾，有感而发。

已经是老回复了，我也是复习了一下前因后果之后，很费时间。
我之前确实理解错了。
19 年 8 月的时候，我还是支持自研接口自动化平台的（当时我也在写这些），而到今天，我几乎是反对自研接口自动化平台了（主要是性价比不高，同时测试有其他更重要的自研工作）。
我的立场已经变了。
希望虫师未来能分享更多的知识，感谢。

看了一圈评论，全是大佬……

透彻

大佬，没有你的微信，所以在你的帖子留言

刚刚结束的互联网测试大会相信你也去了，普遍反响爱奇艺这套 UI 自动化讲的非常好，对其中有两点疑问，

针对弹窗，他们的方式是 AI 训练，识别弹窗，点掉，一个疑问是这样的成本是否太大，对于非那种一流公司的我们来说，没有 AI 基础，要做这个现不现实，还是说只是通过这些东西学习，以备他用。

第二，他说这个全程监听，想不出如何做监听，我能想到的是，跑每个用例时，同时跑定时任务轮询这个弹窗是否出现（BackgroundScheduler），他说的全程监听，是否有更好的方法？

没有过 1000 个 case 的就不要说话了. 不管怎么样 从实际作用来看 测试平台就是伪需求.

现在还有不懂脚本代码的测试吗？