汪汪汪

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

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

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

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

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

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

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

王婆，你这瓜保熟吗？

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

适当的推广我认为是可以并且鼓励的，毕竟再好的平台，别人需要学习成本和改变习惯，一般都不太愿意去接受。如果设计得好，学习成本低，也更有可能被接纳。所以另一个原罪就是写工具的人是菜逼，要写好一个工具，你需要做好产品，开发，测试三个角色，然而很多人呢，表结构都设计得一言难尽，更别提什么交互。而且放眼望去，十有八九都是做 http 的自动化，当然 http 应用广泛是其一，涉及到点 rpc 什么的基本就傻眼，能力只到那个层次又要强行装逼，最后就是写出来一堆垃圾。然后 ppt 上写出来的效果拳打 ali 脚踢 tx，无他，唯 B 尔。当然就算到这种程度，作为一个自扫门前雪的人，我是不会去吐槽的，毕竟人家锻炼下也没问题，但是过了底线：1 强推，2 让人接坑，那就 sb 无疑。

个人意见：写工具/平台的人应该有 2 个底线：1，不强迫（包括政治手段）别人使用；2，不强迫别人接坑。花若盛开,蝴蝶自来。

确实是这样的，api 式的压测，是基于应用层来进行的，http 也好 rpc 也好，应用层的事情你不用关心了，只用关注会话（场景）层，甚至有的时候就压单个接口，那更简单了，同时成熟的工具一抓一大把。这些都让压起来比较容易。但是在性能分析，优化这些方面呢，两者还是颇多相同的，这也是压测最有价值的地方。游戏压测实际上是一个不怎么讨好的工作，花很多的力气在让压测跑起来上，而实际上这部分并不能带来产出，毕竟压测的目标不是写个压测工程，而是优化和修复可能的问题。但是对个人来说，确实是比较锻炼人，一直在传输层上行走，所在的层次（OSI 模型）越低，能看到的就越多。

那相当强了，完成编解码，然后确定场景时序图，编写场景，还要做一些容错啊什么的，做起来都很麻烦。之前也是觉得编解码那块比较烦，各个游戏千差万别，甚至有私有加密，验签什么的。但是后来写顺手了以后，还是觉得场景那块最恶心，又是体力活。

楼主一般做一个项目的压测大概会花多少时间？