汪汪汪

测试的本质是业务创新到达瓶颈、业务容量膨胀后，RD 团队捉襟见肘的技术力量和日益混乱的需求的矛盾下，无可奈何又难以戒除的安慰剂。简而言之就是：这个版本测试折腾一番以后上线了我们睡得稍微安稳些。这也正是测试卷起来的根本原因，折腾了很多，在别人眼里你无法自证产出，所以大家都拼命左移右移，一边要"建议"产品，一边要"协助"开发。正所谓：搞不动质量搞效率，搞不动效率搞流程，搞不动流程搞统计。然后大家都去搞各种平台，十个有九个烂尾，剩下一个也是歪瓜裂枣。那有人要问了测试的价值是什么？who care，业务挣钱的时候就有你的位置，折腾就完事；业务不行了，你看裁员裁谁先。

wiresahrk 抓包看 tcp 层消息就知道了

痛点是居然要我自己动手压

proto 文件转成 jar 包，然后通过类名使用反射生成 stub 实例，然后解析 method，参数用 json 字符串输入。说起来很简单，但是如果你不会，就会不知所云。建议：第一步，写一个正常的 grpc 调用过程（不包含反射）；第二步，学习反射（用来解耦 grpc stub 依赖）；第三步，把第一步的调用过程用反射来实现，完事。

java 的话，反射可以满足你的想法

全链路压测的主要工作在于基础设施和系统架构的适配，可以说根本不在压测工具这边，你系统改造好了，拿个 jmeter 模拟端头发请求都可以，流量自然而然的传递到下游。换句话说，从压测工具出发谈全链路压测的都是噱头。

很多开源项目是很好的学习榜样，可以获得很多设计平台或者说框架的思路，但是完全基于开源项目，只是做个缝合怪平台的话，要么你的业务项目比较简单，没有特别个性化的需求；要么发展到最后，各种需求让你无从下手，让你的平台成为又一个烂尾的缝合怪。

王婆，你这瓜保熟吗？

看角度，如果是从写&执行的角度来说，直接上代码无疑是最自由的。如果是从管理和度量的角度，平台还是有优势，当然，前提是平台是个 “平台”，而不是 ppt，领导会去看你的代码？不，它只想看大盘。平台的定位不应该是一个代替 code 的自动化工具，而是整个团队研发流程的一个物理约束，具体支撑。退一步来讲，光说自动化，不管是 code 还是平台，都看人，牛逼的 code 也能整整齐齐；不牛逼的，平台也就乱七八糟。