#47 楼 @quqing 你继续装逼，我只是看客

#44 楼 @fenfenzhong 我跟他吵吵的原因更多在于这篇文章明显是以装逼为目的而不是分享为目的，这个目的性很重要。以分享为目的的文章会很落地，从应用场景，解决的问题，相关配置说明不说很详细但也会很清楚。而不是在文章一开始就高调声称此工具很牛逼，非常牛逼，解决了各种各样的问题，列出一堆高大上的让人懵逼的专业名词却连最基本的应用场景都没有解释清楚，好像生怕别人知道一样。但别人究其细节发现不过是现有工具上包了一层而已，根本没有在文中宣称的一样解决了那么多种测试类型的问题。而且对于他人深问的问题一律不回答最后丢一下一句我不保证所有人都看得懂。 这样的分享有何意义？ 通篇我只看到了两个字：装逼。 我觉得既然选择在社区做分享，就得对自己的文章负责任，很多的读者都花费了自己宝贵的时间去阅读去研究每一个对他们有用的文章，这是一个平台，而不是信口雌黄的地方。 如果社区里已经都是各类吹牛逼的水文，那我们还来这里做什么？

#41 楼 @skyofdl 恩，不吵了，洗洗睡

#39 楼 @quqing 如果你觉得你这是在耐心的解释那我也是无语了，从刚一开始我就问你应用场景是什么，建议举个例子。 你就支支吾吾说直接看文章。问你那么多问题，你跟我拽各种文字游戏。最后拽到修改和劫持的问题了都。 质问我测试不应该有严谨的态度么？然后说我恶意攻击。 我真是醉了。 以后我也可以发个文章说我已经实现所有场景的测试人工智能化了。但我不告诉你们应用场景，反正我实现了，我再公司已经落地实践了

#37 楼 @quqing 那你继续玩你的文字游戏吧。一开始吹上天了能解决 UI 测试、接口测试、数据层测试、稳定性测试、健壮性测试、前端性能测试、问题分析定位这些问题。结果就是在自动遍历上加个报文修改和验证，哦对了，按你说的应该是劫持。是我土鳖了，是我不会玩高大上的文字游戏。 但这个工具依旧没什么卵用，根本解决不了文章一开始说的那些问题。哎，作为测试，难道不该有踏踏实实做事，不吹牛逼的性情么？

#34 楼 @quqing 我一开始说的，猜测你的原理就是修改 request 和 response 啊？ 无非就是再加个断言和查询日志。我这说的也没错啊

#34 楼 @quqing 后端测试场景 2

这个不是在该 request？

#32 楼 @quqing 我真的是仔细仔细再仔细的看了。一共就这么几句话。 但是这几句话里充斥着各种高大上的名词，就是没说到底解决了什么问题了

#30 楼 @quqing 这个跟我理解的有什么区别么？ 不是修改 request 和 response 么？

#26 楼 @quqing 我这么说一遍吧，看看我理解的对不对。这个工具的目的是通过自动遍历的方式（假设就以自动遍历为例子），自动的频繁的点击 UI 上的控件。触发接口调用，你的工具在监听 app 的 request 和 response。你可以截获这些报文做修改，假如特意让 response 里返回特别大的数来 check UI 做边界值测试，也可以修改 request 传入特别大的值。这样你来做接口测试和 UI 测试对么？ 不知道我这么理解对不对

#26 楼 @quqing 真没觉得你说的很清楚，通篇文章都是高大上的专有名词，但就是没写解决什么问题了，问你你也不说。。。。真的，这文档除了你谁也看不明白

#24 楼 @quqing 能举个实际的例子么

#22 楼 @quqing 我已经很用心看了，真心没看明白这个工具能解决的测试点在哪

#19 楼 @quqing 我理解你用自动遍历的方式，随机频繁的点击 UI 上的控件来做驱动测试对么？ 然后监控 http 的 request 和 response。 那你说的规则都是什么？ 篡改 response 和 request？ 断言的也是 response？

#19 楼 @quqing 你没有说你再测什么啊？ 规则都是什么规则? 能举个例子么？

#17 楼 @quqing 能举个例子么？

#15 楼 @quqing 我理解篡改 response 就是 mock server，伪造 request 就是接口测试。我没太看明白有什么本质的不同，为什么不会遇到那些问题，难道 request 和 server 同事全 mock 了？ 能再说详细点么

#4 楼 @hu_qingen 恩恩 好的~

#29 楼 @hustar0102 可以啊，这没什么冲突的

#2 楼 @hu_qingen 额，媳妇已然怀孕了~ 这个阶段实在不想折腾了~~

#11 楼 @quqing 模式不一样也回避不了一些问题的

#16 楼 @wen_chang 你搜一下 RAP 吧。我们用来约定前后端接口定义的工具，同时还能当 mock server 用

#4 楼 @quqing《比如字段要取随机数怎么办？字段关联怎么办？字段加密怎么办？接口有执行顺序怎么办？接口执行以后需要检查有没有触发第二个接口的执行，等等诸如此类的内容》这部分没太明白为什么没有这些问题了。 同样如果接口参数个数就改变了怎么办，接口依赖很复杂的数据怎么办，各接口之间依赖的数据有冲突怎么办，各接口依赖过强过长其中一个接口 bug 了导致大部分 case 都失败了怎么办，断言的报文是随机生成的怎么办，断言报文不够还需要断言数据库怎么办，断言数据库也不够需要断言各种 hadoop 集群和文件系统怎么办，功能是异步执行必须等一个执行成功的状态怎么办，已经铺开了大规模自动化测试，但是突然接口，UI 等都发生了变化怎么办。等等等等，感觉要考虑的情况很多

#2 楼 @ycwdaaaa 另外用例管理平台也不一定只有 test link， 免费的还有 bug free，禅道也有免费功能。 你可以挑一个适合你自己的项目的。如果公司肯花钱买商业软件，功能就更强大了

前期就用测试管理平台也没什么不行得，不一定非得等产品稳定之后再迁移。没人逼你在用例管理平台上写用例就一定得把详细步骤写清楚。 就算光写个 title 当 check list 也是可以的。规矩是死的，人是活的。用例管理平台的优势不仅是给你个地方管理用例，它也相应的跟踪了每个迭代的用例执行情况，将测试信息展现给团队中的所有人等等