效果很好：https://github.com/PaddlePaddle/PaddleOCR

耗时不会特别多，以我的经验看，CR 在执行测试之前，一个需求的代码 CR 典型时间是 1-2 个小时，但是需要这段时间保持高度的专注，并有以下作为前提：

1. 对测试项目整体的服务架构有一些了解
2. 对这个需求内容十分熟悉
3. 对所使用的语言有些熟悉

要想发现比较多的问题，一般建议 CR 之前，先自己想一下如果你来实现这个需求，需要改哪些模块，怎么实现，难点在那里，然后再具体看对应实现跟你的想象做对比，查漏补缺。通常会发现一些实现逻辑不对、不全的问题。
至于偏语法、语言的错误类型，需要对使用的语言有比较高的熟悉度，知道常见易写错的点。当然，现在随着大模型普及，完全可以让 AI 做这一层的工作，实际上 AI 也能做的更好。
另外是对于经常合作的开发，应该了解他的能力和经常会写错的地方，CR 时要重点关注，这点在小公司比较普遍，大厂的研发通常不会犯很低级的错误。
CR 还会带来后续的好处，先 CR 之后，在实际测试阶段对于出现的问题定位会更加的高效，长期积累也可以提高自己的能力。

给每个开发买一个 GitHub Copilot 就可以了。

我说的就是这个问题，实际上应该更为具体，比如写明具体的订单编号（通过这个订单编号依赖于之前的用例生成），或者指明订单的特性，比如 “最近一周的订单”。只有这样具体的测试用例才是有可能把用例编写和执行解耦的。

为什么要强调编写和执行解耦？这会带来很多收益，例如：

1. 可以把用例编写和执行拆分更小的工时单元，可以更灵活的安排排期。避免忙的时候忙死，闲的时候没事干。
2. 用例编写执行可以分给不同的人做，典型的是正职员工写用例，外包执行。

这就是大厂里面重业务逻辑测试部门在推进的事情，也是为了降本增效。当然客观的讲这个事情实际不是这么理想的，执行用例的人还是会有熟悉需求的成本，意愿上也不太愿意纯执行别人写的用例。但这个事情在领导层面看来有上面提到的收益，就会推进。

其实写不写用例也是一个看 ROI 的事情，写用例无疑会有很大的成本，只有尽可能多的扩充收益，才能把这个事情推动下去。

“应该尽量设计通用的测试用例，避免过于细致的描述。”
这条就不对，测试用例是根据需求容量和测试投入来确定范围的，而不是尽量设计通用的测试用例，不知道是啥意思。
避免过于细致的描述也不对，测试用例应该是具体可执行的，最理想的情况是在多人协作场景下，写用例和执行用例可以不是同一个人，而且比同一个人完成写用例 + 执行用例的工时不会显著增加。这才是写测试用例的价值之一。

宇宙厂就是偷偷用 bug 数、case 数、工时这些给外包排名的，后来外包发现了，就开始拆分 bug、拆分用例、增加工时了，甚至出现一个月 21 个工作日，登记工作 30 多天的情况，但是没人在意，只需要淘汰排名靠后的即可，大领导也借此完成降本增效的 OKR。

简单说，在脑力活动占主导的工作中用指标打绩效，大部分场景最后对整体的收益都是负向的。坚持这么做的原因无外乎两种情况：

1. 领导能力和手段都非常有限，没有更好的办法激活员工的主观能动性。
2. 领导也清楚不合理，但是他别有用心，或者不在乎。

不要用 Jmeter 测试方法的性能，一般的方法如果是存计算逻辑，耗时很少 Jmeter 无法满足这种很低耗时的性能测试（它本身的测量误差都比方法耗时大）。能实现高精度性能测试的是 OpenJDK 开源的 JMH：https://github.com/openjdk/jmh

不建议去，你这个年龄和工作时间很尴尬，去大厂例如字节大概率 2-2，薪资估计也就 35，其实没多多少，但是风险和不确定性很大，工作强度也会大幅提高，完全不值这点涨幅。

你需要的是 web 自动化测试框架，例如 Playwright、 Cypress

对社区的付出真是有目共睹，respect！

我之前在育新住，离你说的地方挺近的，但是现在搬到人民大学这边了。你小时候训练过那有基本功呀，可以约一下～

试试这个：https://github.com/PaddlePaddle/PaddleOCR

举个例子，比如微信，可以聊天、朋友圈当做两个功能，拆分开。确实依赖于 app 的业务形式，有些比较适合，拆分相对来说是个低频操作，可以结合构建系统实现自动打包拆分包。

说一个思路：既然 app 太复杂，覆盖不完全，可以降低 app 的复杂度。在某些 app 功能相对独立的场景适用，把不同的功能模块分开打包测试，比较容易能完全覆盖。

如果是要这个功能，那基本上网关产品都有这个功能。
如果是面试题，高性能、高可用这要求不低呀。

歪个楼，正常人的发量在十万这个级别。

1. 如果后台代码对外部请求没有做配置化，直接改代码为 mock 地址，mock 服务可以分情况 mock 或者 proxy 到正常服务。
2. 如果配置化了，比如配置文件，就修改配置文件。
3. 更好一点的，现在服务框架可以根据请求 header 动态路由，这样就可以从前端控制请求是不是走 mock。

感谢社区，慷慨大气～

的确目前网络上还没有相关的资料。

指出一个问题：

性能测试工具功能对比：

这部分显示 Jmeter 不支持测试过程调整压力，其实是可以的，我们内部的性能测试平台就实现了这个功能，思路是压力设置的地方使用变量，Jmeter 开启 BeanShell 支持，beanshell 支持远程修改变量的值（当然能力远不止如此），就可以动态修改变量的值，实现灵活的压力控制策略。

locust 也是支持的，它自带了的 web 界面就提供了这个功能。

典型的 XY 提问法，建议看看提问的智慧手册。
回到你的问题，把参数放一起作为一个 dict，你原来的参数名字对应 dict 的 key。不管调用还是函数中使用都很方便。

也经历过新人阶段，认真回答一下：

1. 从软件工程理论的角度看测试是很重要的一环，因此不存在天花板低的情况。即使是现实世界中大部分人的职业生涯触还碰不到天花板。之所以有这种说法，那是因为质量对于大部分软件产品都不那么重要，所以对测试的资源投入不足。例如通信类、航天类质量至关重要的领域，测试就很重要，也很有技术含量。对于大部分从事的互联网行业，测试确实知识面比较杂，一个人精力有限，进一步的会感觉什么都不精。如果现在不知道从何下手，其实可以学习一些计算机专业基础知识，这些知识很长时间都不会过时，对你日后的工作、跳槽面试都很有帮助。
2. 自动化会涉及到投入产出比，工作中的事情其实都要考虑投入产出比，有些产品、或者有些产品的阶段就是不适合做自动化测试，不必强求。
3. 不要过分关注绩效，这个东西很大程度你是控制不了的，你的领导是什么样子的人，你在的团队，公司的成长阶段可能都比你的付出重要。至于领导给你解释的绩效理由，你听听就行，其实没什么意义，是先有结果再有解释。你的长期价值会在招聘市场中公允的体现出来。
4. 适合不适合自己，自己喜欢什么，这永远是你要问你自己的问题，也只有自己能探寻答案。不要太在意别人的肯定与否定。

挺好的分享，很多看法都有同感。
看完有个疑问，你对你文中列出来的点很多是否定的，那么你现在招人看重的点有哪些？

还没招到，欢迎大家投递简历～

详细说说？想了解一下那些算是 shell 里面的高级内容。