浅谈一种man in the middle for tester的测试方法。

首先思考如下几个问题：
1、你测试的接口有多少个？
2、最长的响应时间是多少？
3、GET，POST，PUT，DELETE等方法各有多少个？
4、content-type都是什么格式的？

仔细的思考上面的问题，都是量化的问题。但是测试人员往往是站在用户角度思考问题，比较感性，很多事情不一定记得住。只有把数据拿出来才能回答上面的问题。
服务端拥上述最全的数据，服务端有分析上述数据的能力，但是不一定有分析上述数据的意愿和时间。
前端（泛指大前端）有部分分析数据的能力，例如某种埋点机制，但是前端也不一定有这样的意愿。
其次，只能思考从测试的角度如何获取对应的数据，用来支持质保工作。稍微的思考了一下，man in the middle 可能是最好的解决方案。man in the middle几乎可以和代理放到同一个语意里面。其最大的影响在网络层的影响，几乎可以忽略不计。

其次不得不承认，这个人的思考和做法确实很有借鉴意义：
https://blog.csdn.net/weixin_43865008/article/details/122842234

思考一下如下几步操作：
1、代理
2、在代理的过程中将数据保存
3、利用代理保存的数据进行额外的工作，例如diff、mock、replay、generate testcases 等等
4、数据分析

第一步有哪些工具可以提供支持呢？
wireshark
fiddler
charles
mitmproxy
devtools

手工测试时候，我可能倾向于使用charles或者fiddler。
但是灵活性唯有mitmproxy能够满足我的额外的需求。

第二步代理数据保存
保存至文件，文件格式txt、json、yaml等，我再yaml和json中纠结，先不管吧
保存至数据库，mysql or sqlite 关系型数据库，或者mongodb, clickhouse, es??? 初步选择 sqlite，原因就是足够轻量级，可以不用依赖于网络。

第三步代理数据处理
diff? 先跳过，服务端接口格式的变动导致前端不再兼容。但我现在不想diff.
mock? 也没有太多的意义。与其mock这种东西，还不如mock第三方数据来得有意义，例如短信、支付、三方依赖等等。
replay? copy as curl 这个技术上应该不难，但是细节可能得拉满。而且大部分人不喜欢用curl，几乎就是白扯。
现在剩下的就只有generate testcases 了。有一个词叫做脚手架，测试用例细节的复杂度等价于人脑，但是测试用例的骨架的复杂度就比较简单了，生成骨架有意义吗？

第四步 数据分析
时间维度
内容长度维度
数量维度
参数复杂度
接口命名规范维度等等

有时候，一个url可能会被认为是一个接口，实际上却并非如此。有些developer喜欢使用urlpath作为变量，这样url就是动态的了。即使url固定，那么参数也是可变的情况下，我们也不能理所当然的认为一个url就是一个接口，毕竟冰山水面上的部分只是很小的一部分。应该以接口参数组合的复杂度来衡量。

思考完毕，后面主要是代码，看看能不能满足我的需求。

---

白骨露于野，千里无鸡鸣。我起初以为这句话是杜甫写的，后来才知道这竟然是忧国忧民的曹操所写，对孟德斯鸠的态度一下就发生变化了。
月明星稀，乌鹊南飞，绕树三匝，何枝可依？
朱门酒肉臭，路有冻死骨。