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

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

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

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

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

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

什么意思？

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

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

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

你得找出更多信息，比如运行时 _TIMING_OUT 是你想要的 _TIMING_OUT 吗？打印一下出错的时候看看。
WebDriverWait 这里用 lambda 、星号变复杂是为了做什么呢？把复杂的代码拆简单，记录更多的中间状态。

现在觉得每个人知识的积累是最根本的。图形界面方案 (我不愿意用平台这个词) 带来的很多现象都让我想到洋务运动。

当做一个严肃的软件工程看待测试代码，可以做出效果很好的东西。只当做零散的小脚本，最终就是一些小脚本。
其实能专注做一段时间，三个月可能就够代码方案超过图形界面方案的效果了。长期来看这样行业才能向前。

以前在小团队这样用的，也不是生硬切换的，开始有一些人写自动化代码、另一些人提供用例，还要找个地方记录两边情况同步状态，后来发现需要的信息都可以在报告体现不用产生多余的文档。再后来有很多准备写自动化的用例并没有自动化，留在那发现和其他方式写的用例也差不多……大概是这么个演变过程吧，不过后来好几年没研究这方面了

就帖子里写的那样

是的，虽然用单元测试框架但可以没有单元测试~

没有用脑图，层级和节点是用单元测试框架和 HTML 报告体现的，测试过程每个人本地有一个版本。

以前也想过这些，结果想出来这个用 Git 、自动化测试框架和报告管理手工用例，因为觉得这些问题已经在其他 IT 技术领域有很好的处理方式了，如果使用者有技术背景、或者在学习上愿意投入，这是个非常大的可利用的优势。

哈哈哈，熊节老师的文章吧，好多年前看过，熊节老师写敏捷的文章也很好。
再推荐两篇，我觉得都是管理问题
如何打造一个搞垮公司的中台系统？
微服务把我坑了！

一码归一码，如果是个广告系统，提过 “某情况下，A 的预测点击率应该比 B 高” 这种 bug，改完 A 比 B 高算解决。
图像识别可能就提 “这张图没识别出来”？改了能识别算解决。

我只有校招才会问这些面试题，而且也不会这样直接问

将 iPhone 设置还原至默认状态

不用 -s examples/addons/nonblocking.py，mitmdump 也能抓到 grpc 请求的。
没用过from mitmproxy.script import concurrent ，用官方文档的例子 grpc 也是正常的 https://docs.mitmproxy.org/stable/addons-scripting/

直接代理是指什么呢？mitmproxy 代理后不影响客户端功能，Charles 会影响。

1、2、3、4 jenkins 都可以做，5 和主题也没什么关系