看了。可好了。

可以把这个业务场景需要哪些最外部的接口都给列出来，然后分析调用的时序 (先调 a->b->c 如果支持多种选路径最短和产生数据压力最大的) 和执行一次，这些接口分别调用次数，写成一个文件
如果需要程序 mock 一些接口的，需要确定 mock 掉的接口对于你现有流程是有压力的。
这个就是分析时序的地方，需要分析哪些可 mock，哪些不建议 mock，比如 mock 后把后面整段逻辑都砍了，这样压测也是没压力的，因为一个小的完整链路是空壳子。
然后根据时序的文件去添加一个字段叫调用频率，这个调用频率会等比缩放到你压测连接数上面。
还要知道最终压测目标是高频压负载还是只是跑稳定性等等，或者是先压核心模块在全量压等等

https://testerhome.com/topics/27935 第三章的链接，里面还有一二章的。如果没看前面的，建议是按顺序看。

code 是不够的，可以去断言回包里面的某个字段信息，这个信息可以放到类似 response 区域下面，去 json path 去获取验证内容是否符合。
response:
关键需要验证的 key:验证内容

一劳永逸，可以在根目录里面加个文件，里面有个变量 project = os.path.abspath(os.path.dirname(file))
然后其他地方引用这个文件 os.path.json(project,二级目录,xx) 一路拼接过去就行。

其实感觉你已经写出来了啊 unpack 那段。也可能是我没理解你的问题，要不再补充点我再给答复啊

1.一列特别长是把传输的协议变成 Json 了吗，如果用 excel 做，这样是比较长的。
以前考虑过做一些压缩，就是把必填的不传入，根据场景名传入，后面发现很容易忘记和不好维护。excel 表里面可以用 Json 格式化来稍微好读一点。
2.参数还需要某个协议的某个数据取值 这个需要存上下文，上文（上面 case）对象存到 redis 定义 key 为 string，value 就是具体对象，比如 guild_key 公会的 key，是用 {{guild_key}}做模板的形式，遇到解析{{}}之前的就从 redis 那边读取。
3.培训起来是都有成本的，毕竟一开始学代码时解析多层 Json 数据也是难点，怎么填和修改 json 对象才能达成好的效果，建议是多写文档。

插件化是一种思路，但是建议是做内部服务，tapd 做一个 saas，包装 buginfo，关键场景等等定义一系列数据结构。钉钉 api 做一个 saas，中间层一个 pm 服务的 saas（包含多少时间未处理提醒和流转状态等等），这个 saas 去统一调用二边。企业微信等价 tapd，稍微麻烦点，需要拿组织架构权限和再申请一个应用。

目前看来有着一些焦虑和不确定性。
可以试试往大数据这些风口行业去转，额外找一些兴趣爱好。我目前业余时间在学中医给自己开药和针灸。目前胃病比过去好转不少了。

建议这块用单测的方式，如果涉及一些服务之间的切换的，可以用 lua 调战斗的动态链库。
写下单测也是一种积累，可以当成一种扫描，分析了下，这块应该不用 mock 会比较好，能 mock 的也只有是否真实进入战斗还是本地虚拟计算一次，其他的还是要触发一次逻辑的。