#25 楼 @quqing 呵呵，文字游戏玩的真六，转移话题也六，咱们在讨论这个帖子的内容，你却跑去说另一个帖子。 文字有些界的大拿。 你文章中写了我再文章中对自动化测试的理解不对，轻视自动化测试用例，这些我都反驳了，我都澄清了。 你咋不之声了？ 至于测试=QA？ 我就更呵呵了，我回帖写的清清楚楚了你说 QA 和 QC 的区别的错误。 你现在又来反问我？ 跟你这种人说话真是浪费时间。

#23 楼 @quqing 呵呵，说不过开始换话题了么？ 来，你详细说说我哪概念混淆了？ 关于 QA，关于自动化测试，关于测试用例。我在这里都回帖澄清了？ 你回答一下啊？ 怎么不说了？ 你这篇文章不就是在说这些事么？

#21 楼 @quqing 你是又想玩文字游戏么，又跑来说概念混淆问题了。 你指出我概念混淆的地方我都在刚才的回帖中说明了。 你这断章取义做的很漂亮。 如果你想讨论一下。 能回答我刚才说的问题么？

#19 楼 @quqing 如果你不是针对我，为何在我之前的帖子里只放狠话，不讨论技术细节？ 如果你不是针对我，为何故意曲解我的文章？ 如果你不是针对我，为何专门开帖子引战？ 你想撕逼明说，说的好像谁怕你一样

#17 楼 @Lihuazhang 我本就是这个理念。只是这位仁兄专门在我的帖子下放狠话也就罢了。我也没理他，现在又开贴几乎指名道姓的引战，而且你还艾特我了。我就来澄清一些事情而已。 他在泄他的私愤，我不能就这么背黑锅。

#14 楼 @seveniruby 思寒看一下我的回复

#13 楼 @Lihuazhang 有些东西我不想明说，但既然你都艾特我了，我觉得我还是来给你讲讲我跟这位仁兄的恩怨。要说我俩的恩怨可以追溯到我刚来 tester home 的时候了，那是我测试开发之路的第一篇帖子，那时候这位仁兄就因为我的帖子上来引战。然后前几天我们在一个技术贴的讨论上他又开始了嘲讽模式，那一次我没忍住，跟他吵了起来，现在他是专门来再一次开贴引战了。 别的不多说，我上几个截图。

我和这位仁兄的恩怨

还有很多的记录我不发了，这位仁兄最近专门挑我写过的帖子找事。 你可以看到留言根本没说我为什么错了。只是没有任何营养的来那么很装逼的一句：你丫的错了。每一次我都懒得理他，只是他不停在找事而已。自动上次我俩吵完以后，我便本着老死不相往来的态度来对待这个人，你发你的贴，我更我的文章。井水不犯河水。 所以在我俩有这么大仇怨的前提下，又是这么带有个人针对性帖子，我真的是懒得理。如果大家真把这篇帖子当成纯粹的技术讨论那我也没办法。你也看到我第一张截图上的聊天记录了，不只我一个人觉得他卖弄文字游戏。上一次我俩吵是因为他强调修改和劫持的问题，指责我不严谨。 呵呵，所以这篇文章一出来你可以看到，又是一个文字游戏大战。说起 QA 和 QC 的区别来了， 随便找了个国外大牛的文章来佐证他的观点。这个东西怎么说吧，我给你举个例子，在瑞典加班是犯法的，我如果引用瑞典人的说法是不是咱们中国所有公司都在犯法？我心里是呵呵的。 在国外的某些软件公司环境下 QA 和 QC 是这么定义的，所以不理中国国情把他生搬硬套到国内来，我心里更是呵呵的。大家可以扪心自问一下你们见过几家公司是这么区分 QA 和 QC 的，甚至会真正区分 QA 和 QC 的。如果你的老板让你做一件事，你说那是 QC 干的，我不干，你说你是不是疯了。随便在书里网上看一些理论知识，根本没怎么实践过就强行拿出来分享并让他人按你的理念实行的做法我是真醉了。

关于自动化的目的

此仁兄的文字游戏功底之强悍我叹为观止。引用我文章中自动化的目的不是为了发现 bug 这半句话，决然不提后半句。 我后半句写的明明白白，为了节省人力，节省资源，节省成本。可这位仁兄半字不提，断章取义。然后又引入到自己的节奏去了，我心里是呵呵呵呵呵呵呵的。我觉得大家还是看看我原来文章比较好，不要被人误导了

关于测试用例是初级阶段

这明显又是一个断章取义。我只在文章开头的第一句提过一嘴。之后我列举了当前行情下 QA 应该有的 7 大能力。跟这 7 大能力相比，设计用例明显就是个初级阶段。而且这位仁兄又开始玩文字游戏了，他开始偷换概念了，他把我说测试用例是初级阶段偷换概念为我不尊重测试用例，事实上我文章中没有提过哪怕一嘴这样的话，我只说了设计测试用例的能力是 QA 的基础而已。这文字游戏玩的。。我继续呵呵。 退一万步讲，抛开我的文章来说， 设计用例不是 QA 的基础能力？ 初级 QA 可以不用设计好用例？ 难道这个世界已经疯狂到把设计测试用例当成高级 QA 才有的本事了？ 如果是，我道歉是我对 QA 的要求太高了。

总结

所以这篇文章，我理解只是这位仁兄来报仇来了。 各位当笑话看看就好。对于只是因为转发了我文章就喷 WeTest 的状况，我表示我们大家都很懵逼。对于这位仁兄，我说一句话：你有你的逼格，我有我的原则，三十六重天天，一重一境界。前路走好不送。

#21 楼 @quqing 期待你对 QA 的解释

#10 楼 @jaychang1989 话说端口号感觉怪怪的呢。。。。mysql 不应该是 3306 么

#10 楼 @jaychang1989 你换个远程的试试

#8 楼 @jaychang1989 就是连接不上数据库。 你连的 local 的数据库。但是 local 的环境里没有启动数据库的服务

#9 楼 @cyj86 没想到这么久了还有人回帖哈。 我说说现在我的情况吧。 除了外围的测试外，我们终于设计到了性能测试。 即便产品的核心是机器学习算法。但是产品不是只有机器学习。毕竟这是个建模平台。所以还是有大数据处理系统的。在努力学习了 spark 和 Hadoop2.0 之后终于可以测试性能了（之前不懂 spark 这些东西，都不知道怎么设计数据分布）。同时由于在学 spark 的时候顺便学习了 scala，也可以帮着 RD 写集成测试了。不管怎么说。算是个进步吧

#12 楼 @simple 我只用 java 的覆盖率工具，jacoco，推荐 jacoco

首先自动化测试，不论是 UI 自动化还是接口自动化都是为了节省人力成本而不是为了找 bug。 第二移动端刚开始做自动化的话确实接口测试比较好。因为移动端的 UI 自动化成本比较高。不同的平台需要不同的框架，也就说你要写好几套代码去测试。 不像 PC 端，webdriver 解千愁。 第三，使用 jmeter 也好，soupui 也好，都是过渡阶段。以后 case 多了肯定得重写。 因为这些工具应变力比较差，开发那边随便改改你这边就得改一堆 case。 当然如果你们产品小，接口少，也没打算大规模铺开自动化。那就当我没说

#9 楼 @simple 对了还有个问题，不知道你碰见过没有。 就是有些参数之间是有逻辑关联的。 例如如果参数 A 取值为 x，那么参数 B 必须从 1,2,3 中取值。如果参数 A 取值为 y，那么参数 B 必须从 4,5,6 中取值。不知道我表达的清楚么。我现在的产品中不少接口都是这样的。碰到这种接口的话，自动化生成 case 的规则就变的复杂了。

#4 楼 @simple 关于 case 穷举问题，是我理解有些偏差。而且既然你们的 SDK 不依赖数据库，文件系统，缓存等设施，真的是太适合做自动化了。很多问题确实已经不是问题了。 那么咱俩讨论一下目前最大的痛点：bug 的定位吧。

1. 我们之前干过这样一件事，report 中可以选择失败的 case 并重跑，重跑的时候代码覆盖率工具走起，举个例子假如你有一个接口的 N 个 case 失败了。就选取这个接口失败的 case 重跑并统计代码覆盖。我们看看是在哪一行或哪几行抛的异常。
2. 我想你们 SDK 应该有日志吧，你可以监控日志的关键字：例如 error，exception。并截取出错误信息显示在 report 里以辅助 bug 定位。当然这个比较依赖 RD 的日志规范。

我暂时就能想到这两个办法了。

我看了 20 来分钟，还没有详细的抠楼主每一句话的意思，所以可能理解的不是很正确。楼主勿怪。

工具值不值得做

我先来聊聊这个问题吧，因为楼主一开始就提到了。 首先这个工具是有作用的，没作用的话楼主也不会研究这么个工具了。对于楼主的钻研精神还是点赞的。那么接下来我们谈谈资源控制，到底该不该做这个工具其实社区里没人能告诉你，因为我们都不太了解你们的产品，业务，研发流程，人力资源等等。我们在公司做事都是以结果为导向，所以在有限的资源下我们的做事方式是这样的：

1. 首先列出所有要做的事情
2. 为每个事情评估优先级 (可以按风险评估，可以按投入产出比评估)
3. 把资源都投入到高优先级的事情上去

管理者都是上面的思维，他们要考虑当下最大的痛点是什么。当前需要多少人力来做业务测试 (手动) 产品质量才不会出问题。然后想的才是派几个人做自动化来慢慢减少手动测试的人力成本，再然后才是让人做工具的开发和创新，工具的开发也会排个优先级，哪个是最能减少人力成本的就先做哪个。在他们心里考虑的最多的是人力，是资源，说白了他要保证项目的平衡和稳定。 而工程师的想法就很简单了，觉得这个工具有挑战，能解决一些问题他就想搞，工程师的心里一把是没有什么资源，人力的概念的。 所以往往技术人和管理者在做一件事的时候总是会发生分歧。技术人有技术人的情怀和追求，管理者有管理者的现实和无奈。其实两边都没错，站的角度不同而已。我是比较倡导我们这些做技术的人要务实，因为有些时候真的可能捣鼓很长时间的东西，确实没怎么减少人力成本。主要优先级的问题没解决，倒是解决了一堆边边角角的问题，然后产品由于主要优先级的东西挂了。这时候其实很悲剧的。你很努力，但是从结果导向来说，大家加班的还是得加班，产品质量不好的还是不好。

所以不清楚楼主的团队情况很难定义到底值不值得做这么一个工具。这个要靠楼主自己来判断了。不过工具有用是有用的。这点没问题。

楼主面对的问题

我们来说一说楼主设计这个工具的初衷吧。主要是为了解决列出的这 7 个问题。我说说如果是我再不设计这个工具会怎么解决吧。

1. 首先前三条：这个说实话靠个人力量改变不了什么。只能尽量推动 RD，产品和 QA 商量出一个好的流程。我承认有些公司的流程固化后很难改变的。人人都对变化有抵触情绪。但没办法，我们要尽量去推动流程的改善。其实这个才是高优先级问题。为什么前后端步调不一致？当初做需求和排期的时候为什么不能前后端统一步调？找出问题然后优化流程是从根本解决问题的思路。我知道这很难，但这是治本的方法。我们的团队已经找到了好的方式，把需求拆分的很合理，前后端不会出现互相等那么长时间的情况，虽不是无缝粘结，但也都是尽早联调，尽早提测，尽早发现问题，这是互联网人的思维。我们实际上发现即便联调前做好 mock server 的测试也是远远不行的。联调的时候问题百出，只有尽早联调尽早发现问题才能把风险控制下来。楼主做的是一个以技术弥补流程的东西，算是个无奈之举。楼主可以看一下 RAP 这个工具，前后端接口管理和 mock server 都有。
2. 第四条，缺少服务端测试环境，可模拟的真实广告内容太少：为什么服务端会人手不足导致没有测试环境？我理解环境部署不应该是自动化的么？ 为什么会有人力问题？楼主可以看一下我之前写的环境管理的文章，以 docker 为驱动，每个模块出个镜像就行了，我们连 hadoop 集群都能做镜像，广告应该也能把。当然我不了解楼主公司的情况。我只是提个解决思路。 我们的经验是一定不要让环境问题成为你的问题。如果环境没搞定，那就优先搞环境。
3. 第五条，协议字段太多，传统的测试用例设计方法容易出现遗漏：从楼主的描述看，楼主倾向于把几乎所有参数组合都运行一遍，所以才想到自动生成 case。但是从软件开发的角度来看你们的软件不可能这么复杂的，不可能每一个参数组合都对应一个分支。楼主的工具在穷举一个很大的集合去调用接口。那么这种针对性比较弱的测试的效果先不说，其实可能比较好，只是我没有试验过，再一个就是运行时间问题，这么多的调用会运行多少时间？可能我不太了解楼主的 SDK 的接口是什么情况的，软件行业中很的接口调用都涉及到了数据库或者一些文件系统的操作。如果按楼主的思路大规模铺开的话，没准就是成千上万甚至更多的接口调用，如果运行时间过长，其实也是个问题。过多的 case 对于 bug 追踪也不是好事。因为一个接口的一个逻辑 bug 了，可能导致你数十数百的 case 失败。你很难判断他们是不是由于一个原因失败的，毕竟一个接口出现好几个 bug 的时候也不少见。所以其实既然已经到了接口级别的测试，那就已经是半个白盒了。我们做更有针对的测试是不是更好一点。通过阅读产品源码设计测试用例，做到有的放矢。 通过覆盖率工具佐证和辅佐 case 的补全不是很好么？QA 了解产品源码对于测试用例的设计是很有帮助的
4. 第六条，测试用例设计极容易受需求影响，变更起来非常麻烦，成本很高：这个谁也避免不了。这一行的唯一不变的事就是需求永远在边。其实这条跟上面的一样，我比较喜欢有的放矢的测试用例。
5. 第七条：手工测试方法效率低，且容易漏测：这个就尽量自动化么，没啥分歧的。

疑问

楼主做这个工具是为了 mock 服务端的 response 来验证 client 端，但是能自动生成 case 和验证返回值对吧？ 我有点懵逼，文章里没太描述验证 client 端的东西。是只在 SDK 调用的时候验证 error_code 么？

总结

总的来说楼主的这个工具还是不错的，anyproxy 虽然我没用过，不过看描述它的 mock 功能还是比较强大的，用楼主的工具应该是可以找到人工测试很难找到的 bug 点，下面我列一点我觉得的问题，我们讨论一下

1. 我们的验证点是否足够：由于我们的接口可能涉及到了很多数据库的读写，或者 HDFS 上的文件或者其他等等。我感觉楼主的工具是验证不了这么复杂的东西，仍然需要人手动，或者其他自动化方式去写 case 和逻辑验证。这个楼主有什么方案么
2. bug 追踪问题：上面描述过。海量的 case 在 bug 追踪的时候怎么解决呢？假如 1 个接口自动生成了 200 个 case，其中失败了 100 个，error code 还是一样的。你能判断他们是由于一个原因失败的，还是多个原因失败的呢？
3. 运行时间问题：上面也说过。不知道你们 SDK 接口的速度如何，我之前碰到的接口都有各种 IO 操作，速度着实不快。这么海量的跑着，会不会造成批量运行的接口特别慢。
4. 节约资源和人力问题：这个上面说过我们做事的原则，我理解这个工具确实没节约资源。之前的测试该做还是得做，UI 自动化，接口自动化还是得搞。也就是说我个人觉得没有解决主要冲突~ 当然了楼主这个工具是可能会发现人工发现不了的 bug 的，毕竟自动生成这么多 case 的组合。但通过这个工具找到的其他人找不到的 bug 的严重级别有多重，我是有点疑问的，如果我们通过这个工具找到 bug 其实不太重要，但是理论上我们在传统的自动化之余又投入了人力去维护这样一个工具和这个工具带来的测试用例，机器资源开销，bug 追踪的人力成本等等。这个投入产出比，我们是不是要权衡一下呢。当然就像我一开始说的，也许楼主所在的项目已经把主要冲突都解决了。 楼主是完全可以搞这样的工具研发的。

不管怎么样，楼主的想法和分享精神是很好的

#1 楼 @xdf 恩，我学习 docker 的时候也看过这篇文章

#8 楼 @aizaimenghuangu 如果目的是让不熟悉产品的人也可以执行测试用例，那就又回到刚开始的问题了，产品业务不稳定的时候用例是很难详细到每一步都记录下来的。那个改动成本太高。这跟是不是用例管理平台其实没太大关系了。产品初期的时候必然是就写一写 check list 的。

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

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

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

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

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

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