只留下一个用例，有代码提交跑一次，有配置改动跑一次，有数据库变更，有重启跑一次，没事 10 秒跑一次。再看看能不能发现问题

我只是觉得只给手工测试用的不行

我从来没有见过能称手工用例为资产程度的情况。基本的作用是科层制的过程指标，或者产研测分工下划分责任边界的工具。叫资产，就要在长时间无需太多努力就能产生利息。
关于测试用例，我听过有重要性的话只有这几句：“像复式记账”，“工作的软件高于详尽的文档”，“就是举例子”。这像从不同视角看一个过程。
“正规的模板” 也只有在很窄领域才存在。在互联网公司常见的工作流程里这个领域空间时间范围都很小。实际写手工用例的人大都理性的用合算的成本去写了。而且不同产品适合的举例方式也不一样，电商购物车、广告计算模块、期权计算、工厂设备收集数据的，明明天差地别，但搜索引擎搜一下用例模板，结果都差不多的。

因为没有这些新词不影响我理解你说的话，有了这些新词妨碍我理解你说的话

举个最近的例子吧，看看 CPTPP 的劳工条款，想想中国要加入的话容易吗？
我觉得把劳资关系类比成交易、谈判、zz 活动都可以，是人与人的关系。想象有一个机械系统把劳资关系类比成机器调试，只从管理学来看，感觉只是古老泰勒工作法的另一个说法。

改下产品代码，只有 release 包才禁止

什么意思？

web 开发来说，前端组建化的结果是，很多输入框的异常值边界值都很难出 bug 了，因为后端框架的成熟，开发也很难写出 sql 注入的问题了。这种例子太多了，大部分情况模仿相比推导是更经济的学习方式，一个老经验的测试方法，总是找不到 bug 的时候，自然会被放弃。但在变革发生时，只靠模仿也会跟不上变化。
每次编译 proto 的时候，不就像执行了一次测试嘛。

我记得有几个参数和限制有关的，看看文档

在 Python 程序中启动 mitmproxy 并控制 addon