#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 啊？ 无非就是再加个断言和查询日志。我这说的也没错啊

#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 额，媳妇已然怀孕了~ 这个阶段实在不想折腾了~~