additional-strategies

5 posts

你的 main 分支挂了,要从 200 个 commit 里找出元凶

Git bisect 把手动翻 commit 变成了自动二分查找。以下是如何在不逐个 checkout 的情况下,精确定位引入 bug 的 commit。

你的 CI 在 main 上红了,但昨天还是绿的。在那之后到现在之间的某个时刻,一个 bug 溜了进来。你可以滚动浏览 200 个 commit,阅读 diff 并猜测。你可以在 Slack 里问,指望有人记得碰过相关代码。或者你可以让 Git 来干活。 是一个针对你 commit 历史的二分查找工具。你标记一个…

你的错误追踪器知道崩溃发生在哪里,但这无法帮你复现它

堆栈追踪告诉你崩溃发生的位置,而不是原因。以下是一种捕获-复现模式,能把生产环境崩溃转化为本地可调试的测试用例。

你确切知道生产环境在哪里崩溃了。堆栈追踪指向 的第 147 行。异常是一个针对 的 。你拉下代码,运行测试,全部通过。你用一个示例 payload 手动命中端点,它工作正常。 Bug 是真实的。客户在触发它。但你就是没法在自己的机器上复现。…

Symbolic Execution 发现了我 94% 测试覆盖率都遗漏的整数溢出

你的单元测试只检查特定输入,而 symbolic execution 检查所有可能的输入。以下是它的工作原理、成本以及从何入手。

你的测试套件有 94% 的覆盖率,零失败。一个 symbolic execution 引擎在三秒内就在你的代码中找到了一个崩溃。 测试没有坏。覆盖率指标没有说谎。问题在于测试只验证特定点上的行为。Symbolic execution 验证的是整个输入区域上的行为。无论你写多少示例,如果 bug…

你的日志正在泄露 PII,而 grep 救不了你

大多数团队是在客户投诉后才发现 PII 泄露。以下是如何从源头到输出全程追踪敏感数据,并附上了今天就能用的代码示例。

大多数团队在客户投诉或合规审计后才发现 PII 泄露。到那时候,数据已经穿越了 ETL 流水线,落入了应用日志,并被三种不同的可观测性工具索引了。 事后发现属于考古学。你真正需要的是一套系统,在数据进入代码的瞬间就追踪…

你的 API 在生产环境崩溃,是因为 CI 在测代码,而不是 contracts

大多数 CI 流水线能捕获语法错误和逻辑 bug,却漏掉了真正拖垮生产环境的 API contract 破坏。以下是修复方法。

我们团队中每一个进入生产环境的 API 破坏都通过了 CI。每一个。单元测试是绿的,集成测试套件通过了,部署发出后,Slack 消息就开始刷屏了。 问题不在于我们没做测试。问题在于我们测错了东西。大多数 CI 流水线验证的是代码能否运行,却不验证生产者与消费者之间的 API contract 是否仍然完整。…