#20 楼 @ycwdaaaa 你的文章本来就存在概念混淆的问题，没有曲解啊，我对其他文章也评论过，难不成都是要开贴引战？难道你只想听恭维的话？你说我在 Mock Better 的文章中装逼，你拿点论据出来，摆事实讲道理，行吗？

#18 楼 @ycwdaaaa 我只是针对你的文章不够严谨，我也注意到有人在其他回帖中引用了错误的观点，一些混淆的观点会影响到小白，这种扩散效应有必要制止，可能是我多管闲事，但这也是来这里的初心。也许话术是我的弱项，容易让人不爽，但恭维的好听的话不一定会让人进步。你别以为我只针对你，我也对其他文章发表过我的看法，我就不说具体是哪几篇了，互动很正常，但如你反应强烈还是第一个，如果把技术 PK 搞成是泄私愤，并进行直白的言语攻击，是不是有点激动了。欢迎你对我那篇关于 Mock Better 的文章进行再次技术 PK，看看是你没理解还是我在装逼，接招吗？

#3 楼 @Lihuazhang http://wetest.qq.com/lab/view/169.html，表面上看是给社区做软广，长远来看，可能会起到相反的效果。

#6 楼 @yangchengtest 你也说了是大部分互联网公司，能代表全部互联网公司吗，能代表整个行业吗？我表达方式比较直接，请包涵。

#4 楼 @dongdong 如果有条件，可以把 QA 和 QC 的活都干了，这是组织架构的设计问题。但作为一篇广而告之的技术文章，两者概念不能混淆。我想表达的是做测试需要有严谨的态度，弄清楚两者的区别而已。

#1 楼 @Lihuazhang 对于腾讯 WeTest 发文的严谨性表示怀疑，这是要坑害多少人

有同事微软出来的，流程规范，代码自检做的很到位，提升质量的关注点不会只放在测试人员身上。

简单实用，技术风格

技术好文，赞

抛开内容不说，文章的方向错了，先搞清楚什么是 QA 吧

#5 楼 @Lihuazhang 懂测试的@monkey，技术牛的@xdf，既懂测试技术又牛的没发现

#15 楼 @anonymous 说的很好，不忘初心，做自己觉得对的事情，即便被误解我想随着行业的发展也是暂时的

看过我的文章的人应该清楚，我的风格基本上都是部分落地或完全落地后再分享的，正如文章开头已说明，这个解决方案虽然前端测试部分已经落地，但还有 2 个需求在进行中，最终接口的落地效果会再次分享，条件允许会开源，谢谢支持我的人，也谢谢那些能看懂这篇文章的同行

#3 楼 @xie_0723 你提的问题很好，我也曾思考过这些问题，以下答案仅供参考：
接口自动化和 UI 自动化的用例是完全重新设计，还是从业务用例中筛选？IF 从业务用例中筛选的话，筛选的标准有哪些呢？（PS：接口用例中的接口参数类型的用例设计，暂不考虑）
－－我觉得接口自动化案例要重新设计，这里涉及到分层的概念，接口层更关注对数据的验证，处理各种请求参数正交场景下返回数据的正确性，涉及到增、删、改的接口还要关注数据落地的有效性。

接口自动化和 UI 自动化，互相之间有影响吗？或者说接口覆盖的用例和 UI 覆盖的用例之间是否有某种关联？IF 有关联，请问需要多大粒度的关联比较合适？ELIF 没关联，请问两者之间各自为战吗？（PS：这样会不会导致测试覆盖率重复呢？）
－－接口测试不一定和 UI 测试有关联，传统的接口测试，不需要等 UI 开发完成就可以介入了，从这点来说属于前置阶段的，通过 Mock Client 实现的接口测试；
－－UI 测试和接口测试一定有关联，因为 UI 层的数据渲染大部分是通过调用接口获取的，在执行 UI 自动化的同时，有很多眼睛看不到摸不着的接口在来回穿梭，这些不是 Mock Client 发起的，而是由真实的程序发起的，场景化内部的参数动态关联等一系列问题，程序都会帮你自动处理。所以由 UI 测试发起的接口测试，只要你能劫持到接口返回的报文，实现起来比传统的要简单多了。

如果 UI 层的用例 Faile，是不是需要定位到对应的接口层？相反，接口层用例 faile，是否需要定位到 UI 层，IF 以上需要，如何有效关联呢？Or 是否需要在分层测试的工程中，让他们互相成为彼此的辅助？
－－UI 层 Fail，接口层不一定 Fail，因为即便接口是正确的，也不能保证 UI 层的数据再处理不会犯错。相反，接口层 Fail 了，与之相关的 UI 层必定 Fail。如果接口层 Fail，我们可以通过一些手段，例如：获取接口关键字、定制 traceID，通过这些唯一性标识去定位错误日志或代码行。

最后，建议你看一下关于 Mock Better 的这篇文章，和你的问题有相关，https://testerhome.com/topics/6121。

#1 楼 @CwXwWw
是否要考虑成本？ 当然要考虑，我们总会遇到在成本和质量之间找平衡点，可能一些特殊的行业，特殊的项目，质量的权重更高点，如果引入自动化能提高质量，该介入的还是要介入。
抓住业务测试工作中的痛点和领导的痛点，多沟通多交流，优先解决基层的工作痛点，我相信一个好的领导会看到你的责任心和付出

作为一篇作文，能给 90 分，作为一篇技术性分享真的一声叹息，可能 80% 的人会认同你的文章，我相信还有 20% 的人和我一样，这个比例就是行业现状。

#131 楼 @l84222780 windows 没测试过，工作太忙，过完这阵会更新的，如果急着用可以自己先研究下源代码

#127 楼 @huangejuan 这边也无法重现，有空我跟一下吧

#126 楼 @l84222780 你 windows 跑的还是 mac，如果是 windows 文件分隔符不一样的

#123 楼 @huangejuan 改成这样试试F:\\ndtest\\traveler\\log，另外装个暴风影音再试试

#121 楼 @l84222780 用源码跑的还是 jar 包跑的？看错误应该是参数错误导致工厂反射到具体 robot 的时候出的问题
java -jar jar 包名 ios/android 配置文件路径

#120 楼 @huangejuan 我这边没法重现，从 2 个方面排查
1.配置文件项发给我看看：例如：/Users/mac/Desktop/png
2.装个暴风影音试试，看看是不是编码问题

#48 楼 @ycwdaaaa 也只有你这种人，看不懂就会咬人，自负又自卑。

#46 楼 @ycwdaaaa 最后悔的是和你这种无知又狭隘的人交流，你是怎么想的就会把别人看成是怎么想的，不是每个人来这里分享的目的和你一样。

#44 楼 @fenfenzhong
关于 1、2，底层还是调用脚本控制 anyproxy 服务的停止、重启及应用 rule file，至于是如何管理和触发的，通过监控 anyproxy 的进程，配合数据库记录的标记位，实现排队处理逻辑。控制入口就是页面上的 “开始录制”、“停止服务”、“启用规则”、“停止规则”。
关于第 3 点，目前是在配置向导，有报文提供参考，一个规则集下可以包含多个规则项，至于篡改哪个字段，篡改值设为多少，由使用者根据测试需求设置，这里说明下，启用了某个规则集，使用完毕停止后才能启用其他规则集，这些在系统消息里面会有提示的。
关于第 4 点，我觉得前面已经尽力解释了和传统接口测试的不同，基于 UI 触发的端到端场景测试，由界面触发的接口调用一直真实存在吧，只是以前看不到摸不着，这些接口的发起不是 mock client 发起的，而是真实的场景调用，所以不需要考虑依赖关系等许多问题，我们要做的只是根据规则命中它，然后和预设的断言比较是否有问题，如果有问题，我们还可以根据接口关键字调用后台日志查询接口过滤到错误的上下文。
我也郁闷了，第 4 点该怎么解释了。。。