#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 也是可以的。规矩是死的，人是活的。用例管理平台的优势不仅是给你个地方管理用例，它也相应的跟踪了每个迭代的用例执行情况，将测试信息展现给团队中的所有人等等

#2 楼 @0x88 这个问题看开发就知道了。他们要应对的变化因素更多？ 他们是怎么做的？ 开发有严格的流程保证代码质量，保证代码风格统一， 有架构师先搭起骨架在让底下的人填血肉，要求文档，注释。 这些都是手段，你再看 QA 写代码的时候有几个严格要求过代码质量的。如果手底下人的水平差，就让测试架构师搭好一个架子，要求所有人都按着这个架子写，严格执行 code review，规定良好的分支策略，编写好文档和注释。开发那边成熟的管理方式都摆在那了。但是用不用是我们的选择。

关于这个问题我一直想写个帖子专门说一说的，就是最近一直没时间。你可以看一下我之前写的有一个文章《测试开发之路 -- 喷喷埋雷的事，吵吵代码的情》。 里面提了几点。这个需要依赖良好的代码设计，尽量把所有可能变化的地方都封装起来。这样将来控件变化的时候能做到只改一个地方就适用于所有 case。 不过确实你再自动化前要评估一下这个模块是不是适合自动化。一定程度的稳定性也是重要的。 接下来的就是别怕麻烦，一开始设计代码的时候就别埋雷，好的设计肯定在一开始的时候要多写一些代码，别懒惰，现在不多考虑一些，之后会痛苦死

#37 楼 @tcat 你可以看看我写的监控式数据管理方式，我通过 assertJ 的 changes 概念写了个工具。 自动对比用例执行前和执行后数据库中数据的变化并拼出 sql 语句，将数据恢复回去。

怎么说呢，如果一个想入行测试行业的人问我该学哪门语言，我会说其他语言都可以不学，但是 java 一定要学好。