parser 倒不是关键，静态分析写的太简陋了，这里面 corner case 挺多的。java 领域比较成熟的框架 soot 或者 wala

看了下代码，我觉得 coca 的静态分析不太靠谱，不如试试比较成熟的那几个

第二个方案用 antlr 不是个好主意，需求越来越多，搞着搞着最后就变成实现一套语言了。不如直接找个支持自定义 DSL 的语言（例如 groovy），在此基础上去实现会好点

vars.put("data", new String(data));

base64 把 byte 转成 string，然后再转回去

技术路线的测开会发现，纯测试开发技术大部分都服务于 QA 或者小部分人群，这些系统都未经标准化的开发管理，也没有外网的海量验证，技术的深度和广度在上游开发看来，不值一提
喜欢做技术，或者转做更上游的开发岗位或者具备领域门槛的研发岗位，专一纯粹去做技术思考和规划，把核心技术深入理解并向架构等方向纵深。

个人觉得这个理解有点片面了，与运维开发不同的是，貌似因为测试的缘故导致多数人总会把测试开发当做自动化的业务测试去理解。当运维开发搞出来 devops，在从架构层面上去改变开发模式，甚至已经开始用云原生去革开发的命。测试开发不要再想着用一个 ssh+vue，写一个所谓的自动化测试框架就是测开的阶段了。
想想公司里测试基建真的有做起来吗？压测是不是还在用 jmeter，能不能做到全球多节点的分布式压测，能不能做到结合监控数据、结合代码分析，做到自动分析代码问题？
静态代码扫描是不是就还在用 sonar，就找人配了几个规则，搞个 ide 插件就完事了？程序分析作为 PL 领域比较火热的一个大领域，能不能做到工业界的落地？
集成测试是不是还停留在接口测试的阶段？复杂业务的全链路自动化测试，在链路上任何一个节点中断、切入这些都能做到吗？
还有混沌工程、流量录制回放、单测生成、用例生成、精准、程序修复……可以做的东西太多了，总结来说就是测试领域的基建还是太落后了。

思路本质就是做 aop，看在哪里做 aop 去改掉原本业务要请求的地址。

比如代码级别的动态配置下发
编译层面的拦截 c/c++ 插桩 java 的 agent，字节码&源码级别的切面 aspectj ASM 等等
机器级别的 libc 拦截、防火墙拦截
中间件级别的 网关统一拦截，配置中心拦截
路由器级别的拦截，这个类似防火墙

当然每一层做都各有优劣势，可以根据自身情况分析分析再做决定

结构化 diff 一般都是将文本解析到语法树，然后通过一些 tree node diff 算法来实现
然后你可以将语法节点本身作为树节点映射，也可以抽象一套通用的树节点，里面包含语法节点名称与值这两个属性，这样获得的结果就通用了

最适合用来做 java 应用单元测试语言的就是 groovy，里面很多特性感觉都是量身定制。
包括元编程，也能应用到很多场景

可以结合，而且结合点很多，主要看你是否有这方面的需求
简单举几个在工作中用到 antlr 的一些地方：

• 文本结构化 Diff，通过 antlr 实现多语言通用支持
• RPC 的 IDL 文件解析，用于实现一些类似 grpCurl 类型的工具
• 程序（代码）分析（一般看情况，如果语言本身支持很好就不用自己写了）
  • 语法检查
  • 数据流分析
  • 抽象解释&符号执行
• 测试领域的 DSL（目前来看这方面容易做，难推广）
• 云测平台，云 IDE 相关都会有需要

议题的问卷和 ppt 要一起提交吗

start end 用来定位某个节点在原始字符串中的 index 位置，前端就可以根据 index 对差异节点进行染色，最后会有这样的一套展示效果

晚点单独开个帖子说一说

和我的解法基本一致，握手。

最后展示标记这里，由于我是做纯粹的格式化 diff 工具，最后放在 monaco 编辑器上进行染色标记，大体思路是：

zjsonpatch 是支持例如 jackson 里面的 jsonnode 进行对比，但是 jackson 在解析的过程中没有携带每一个 node 的坐标信息，所以这里首先通过继承，给所有的 jsonNode 带上 start end 的坐标字段，然后直接用 antlr 重写了一个 json parser，自动造一套 jackson 的 jsonnode（相当于重写了 jackson 的 parser），在解析过程中带上每一个节点在字符串上的 [start,end] 坐标，这样最后拿到 diff 之后给的 jsonPointer 就可以获取到每一个节点的坐标信息

而且这样还有一个好处，就是支持 jsonpath 语法，如果要做例如去噪对比，可以通过 jsonpath 进行过滤掉一些节点

有了点新的研究成果回来回复一下，apk 可以直接打覆盖率是因为 android 内置了 emma 的包，这样只需要对 apk 进行 offline overwrite 模式的覆盖率打包，就可以直接跑起来

是的，这里最好是要编译组件提供一个关于编译命令的切面出来，让覆盖率组件去修改原始编译命令来实现。
再或者 我们可以创建一个覆盖率构建组件，去调用原本的编译组件都可以。
这个实现方案的难点在于需要根据不同的语言、编译器、构建系统的命令，解析 shell，将原始指令修改成覆盖率打包需要的指令，所以不知道业界是否有其他无侵入的方案

以前遇到过，本地启的很快，上来服务器就慢，后来配了 hostname

beanshell 就是个残废，原生 groovy 就挺好

1、让别人低成本，甚至无成本的将现有业务迁移过来
2、能否有一些过硬的亮点功能可以吹？这样领导也好去推

不光是工程量，这里很多东西，测试开发一般是搞不定的，得基础团队做，偏中间件一点

这些东西我们搞了一整年了，反正坑不少。需要专业的开发团队投入大量时间搞。

我们这测开业务比较开发，自研一些测试领域基础工具的开发。比如抓包，RPC 测试工具，回放，mock，对比，覆盖率这些

开发转测开前来报道