大家还是分享学习成果吧，我理解楼主初衷也是想大家分享知识，不是分享网址。。。

从方式上，可能线上流量录制回放比较接近你的需要，里面参数基本都是真实有效的，而且只要日活不低，覆盖率也不会太差。实际上大会上也有见过讲流量回放的时候，提到其中一个扩展使用场景是压测的。

但没明白做个性能测试，为啥要遍历全部接口？

理解。
提个小建议，这么简短的文字估计没法让这类不合适的候选人有产生要改变的感受，而且也容易引起歧义（比如走向另一个极端，不去听任何分享）。建议写个详细点的文章来说吧。

好奇为啥会突然有这样的感慨呢？

你现在看的是商城类的，业务和测试领域差异比较大，你比较需要补的应该是业务领域知识，直白点说就是测试工具的设计思路。

可以想想现在测试工作有什么需要帮助的，比如哪些地方效率低，是否需要做一些测试工具平台辅助。典型的像接口测试平台这种。

PS：如果你出发点是帮助测试工作，建议先想有什么需要帮助的，大概要用到什么技术，再去学习技术。先学习技术，容易陷入手里有个锤子，什么问题都想用锤子解决的倾向。

开发不适合我。。。以前在学校有做过开发类的活，明确了自己兴趣不在这块。

楼上说的非常清晰了，我只补充一个小点：文档积累也会有过时的问题，可以推荐每一个新人在看完文档实践完后，多吐槽甚至直接可以动手去优化文档（担心会改乱的可以弄一些简单的审核机制，改完后导师确认下改动点没问题再发布）。

新人才最知道新人需要什么，所以新人文档，新人参与会很好避免文档发挥不了作用的问题。

哈哈，不错。

保持自己习惯就好，个人喜欢辩证地看东西多一点，所以不大喜欢太绝对的东西。不过观点无对错，期待你后面对楼上说的基于 k8s 支持做流量回放的成功案例分享。

前辈客气了，我还有很多需要学习的，称不上大佬。

这。。。那就转给硬件测试工程师好了。

可以找你 leader 反馈下这个问题，也一起探讨下有什么方法可以优化。

可以先问下给你任务的人他对任务的期望，以及说明你缺少这方面经验，需要一些指导协助？能给你这个任务，这个人应该不至于完全对这个任务一窍不通。

虽然从描述看应该是你本质工作之外，但也不妨看做是一个公司提供的带薪学习硬件测试的机会？

不错的分享，点赞。社区里阿里的同学好像越来越多了呀。

代码怎么快速上手这个，我自己以前也总结过，确认目的->找到对应功能的出入口（比如 controller 层）->从入口开始阅读，期间同时记录 uml 时序图。过程中持续了解用到的框架功能（java 工程有挺多功能是某些框架自带，所以直接看代码体现不出来的，而且框架姿势使用不对也非常容易出 bug ），大体差不多。

点个赞，能在比较大的年纪且测开已经有一定成就的情况下，转开发并坚持下来，Respect！

业务维度，测试站在最底层，对于架构设计的理解是欠缺的。很多好的工具和平台，是在开发过程中造出来的，不参与其中，不知创新的点。现在也在提倡研发效能，如何提升？

对于这个点，个人也有同感，我们常看到的研发效能提升，我个人理解更多其实只是做质量赋能和测试阶段的提效，对于研发流程里面实际耗时最长的开发阶段，提效可能不是那么明显。想问下楼主目前接触开发后，对这个点有什么新的想法可以供测试同学参考不？

这个有点绝对了吧。

流量回放无法解决未上线新功能测试的需要（没有流量可录制），对于接口调用频率不高、数据安全性要求高的 ToB 类业务也不见得适用（流量不足以覆盖大部分场景），还是有自身的局限性的。只是他相比手工写自动化脚本，自动化成本降低很明显，所以比较受欢迎，应用领域也更多是有大量流量的 ToC 类业务。

至于说 k8s 支持后这两个都很简单，没太理解这个点。k8s 貌似本身并没有自带接口回归、压力测试的能力。你想说的和 k8s 组合的 istio 这种服务网格机制，可以更方便控制服务间流量吧？

？

你这个是通过加 java agent 来弄的，属于 On the fly 。至于引入这个依赖，我理解是主要给单测覆盖率采集用的吧？没怎么玩过 java 服务的 offline 插桩（因为 On the fly 很香，没有什么改用 offline 的理由），不大清楚。

也补充说明下，一切覆盖率工具，原理上都得给原版代码加额外代码。加的这个代码主要是一个标记，让给某个指令/某一行代码的运行前后，改变这个标记（比如默认标记是 0，有跑过就变成 1），标识这一个指令/代码行执行了。
只是由于 java 这门语言支持运行时字节码增强技术，也提供了 java agent 这样的不用改源码就能改字节码的玩法，所以才出现了这种特别的看起来 “无侵入” 的加代码姿势。所以官方把这种方式比较形象地称为 on the fly（直译是飞行中，你可以理解为运行中插桩）。

但要注意，因为 java agent 本质上还是在运行时改了字节码的，所以原理上是完全可以改变代码逻辑的（比如 jvm-sandbox 官方例子里的，不改源码直接改变某个函数的行为来修 bug ），接入多个 java agent 也有可能产生相互影响出 bug ，所以不要觉得这个方式真的 “不侵入、无风险” 哈。

@jiazurongyu 大猫知道么？

小程序的菜单不一定属于 webview 的一部分吧，你先 dump 整体界面控件树看看？

@Fhaohaizi 标题帮你改了，不要把正文直接作为标题。。。

看出问题概率高不高，高的话就要在灵活和安全两个里面做取舍，牺牲灵活性。比如收回多部门的编辑权限变为某个部门集中设置，或者每个这种规则的变更都需要上级审核确认后才能生效（比如线上数据库变更的玩法）。

个人理解，测试没办法对所有业务人员的配置正确性负责（权限上线上业务人员权限分分钟比测试还高，测试没法把控），但需要对系统的健壮性负责，即要能尽量确保系统配置不符合业务规则时，能明确提示；对应的降级容错措施能把业务问题降到最低。

不过大部分内部配置系统规则都会比较复杂，全部做校验成本比较高，产品和开发是不愿意的。而且运营人员流动性很大，本身也不一定熟悉系统，配错漏配真的是常事，最终造成线上故障，测试肯定逃不掉要协助排查处理。所以我们内部实际落地还有一种方式，就是重要活动/配置在配置完未发布时，给测试在预发环境进行验证，确保配置正确无遗漏。既然配置容易出问题，出问题后测试都是要投入，事前投入保障没事故，比出故障后费劲排查要高效得多。

行，讨论到此结束吧，我们继续保持双方的观点就好。也希望后续的文章，这些概念性的内容，请做好审核，最好是加上参考资料或者出处，经得起大家的推敲。

关于言论自由这个，也特别说明下，社区一直保持言论自由，这个帖子一直没有被屏蔽就是一个证明。但也请注意，社区的初衷是为了帮助新人成长，提高测试地位，推进质量发展，因此会保持对内容进行审核。遇到内容不大正确，经不起推敲的，会有人站出来指出；太不靠谱的，我们也会直接屏蔽。

每个人角度不一样这个没问题，只是你这个分类，特别是 RPC 和 gRPC 并列，这个分类方法会让新手很迷惑这两个 rpc 有啥差异，实在有点说不过去。

既然要给新同学布道入门接口自动化，内容里给读者一个经得起推敲的指引，这个是基本要求吧。如果有些不确定的，建议特别说明 “个人观点，不一定正确，欢迎探讨”。

hmm，你想办法和领导沟通好吧。

不是所有手工都适合自动化的，也要考虑投入产出比，不要为了自动化而自动化。

现在这个还是不大对。。。我说下我的个人理解。

首先，按网络接口角度，网络接口调用的核心目的，主要有 2 个：把约定好格式的信息，发送给指定的目标

传输协议的目的是为了解决发送给指定的目标这个目的的。有多种协议，比如 http、https、tcp 等。tcp 也是常说的长连接，http 是基于 tcp 的但无法支持任意一方随时发起通知，所以对于一些实时通信要求比较强的，会直接基于 tcp 来进行网络连接。tcp 典型的使用场景有微信的消息传输、直播应用的公屏消息等。至于怎么定义指定传输目标？http/https 用的是 url ，tcp 用的是 ip 。

而序列化方式则是为了解决约定好格式的信息这个问题的，常见的有 proto buffer 、json、xml 等。序列化方式保障发送者和接收者用一致的格式解读数据，确保数据传输正确性的同时根据传输场景进行优化（比如一样的信息，用 json 占用的空间比 xml 小，proto buffer 又比 json 小）。当然，除了序列化方式，部分协议也有定义信息格式这类字段，比如 http header 。

然后，在实际编码中，不管什么传输协议、序列化方式，都得自行基于网络库来建一大堆封装方法，接口多了这部分逻辑也有不少的工作量，所以就有了 RPC 调用，把网络库部分自动封装好，开发不用管底层网络库，直接引用 api 包，调用里面提供好的对象和函数即可，大幅度降低开发的调用成本。

而 dubbo、grpc 属于实现了 RPC 理念的具体框架，由于它们封装了底层的传输协议、序列化方式，因此也具备切换多这个协议的能力，比如 dubbo 支持 http、dubbo、thrift 等多种协议。同样由于 RPC 本身就是一种调用方式，本质就是对传输细节的封装，所以一样会有 一个rpc框架封装另一个rpc框架 的情况。比如 dubbo 底层也支持通过 grpc 来进行调用。

至于 RESTful（Representational State Transfer），不属于以上任何一类，它是一种针对 http 协议的接口风格。核心思想是把最常见的数据库的增删改查，和 http 协议的 post、delete、put、get 方法进行一一对应，便于简化服务端逻辑（这种直接增删改查数据的，可以直接基于数据库生成完整的调用逻辑，现在实际也有相关的工具）。当时时代背景是接口协议定义没有任何统一指导思想，大家随心所欲，经常会出现同样是删除资源，每个人创造一种风格的接口路径（有的叫 delete，有的叫 remove 等），复用度也不高，所以产生了这种定义清晰简单，扩展性复用性也强的接口风格，并受到很多开发的欢迎。只是传播过程中很多一知半解的，把它等同于 http 接口了，讲着讲着变了味。

可能有的人会觉得，概念不重要，也确实很多人即使把概念搞混，也不影响工作。但基于这篇文章是想给新人们宣导用的，所以里面的概念还请理清，避免新人们不同地方看到不同的概念，陷入混乱，这就违背了初衷了。