全栈测试随记
为什么一个开发者要看测试书《Full Stack Testing》这本书不厚，但覆盖了从单元测试到探索性测试的整套方法论。以下不是书的内容摘要，是我读完后觉得真正有用、并且从开发者视角重新理解过的部分。
测试不是找 bug这是书里让我重新校准的第一个概念。
找 bug 是测试的结果，不是测试的目的。测试的目的是提供信息——这段代码在什么条件下正常工作，在什么条件下会出错，错了之后的表现是否可接受。这个信息服务于一个决策：现在能上线吗？
把测试理解为”信息获取”而不是”质量检验”，会改变你做测试的方式。你不会问”这个功能有 bug 吗”，而是问”在所有我知道的边界条件下，这个功能的行为我都看清楚了吗”。前者只有一个答案（有/没有），后者会引导你系统地列出一组场景。
等价类划分与边界值分析这两个是测试理论里的基础，几乎是所有测试方法论的起点。
等价类假设有一个输入值 x，业务逻辑分三段处理：x < 500、500 ≤ x ≤ 1500、x > 1500。理论上三个区间里的任意值行为都应该一致。所以你不必测全部数值，只需要在每个区间挑一个代表。
等价类的核心思想： ...
混沌工程随记
混沌工程目的不是在故意在生产环境里搞破坏。搞破坏很容易，难的是下面这几件事：减小爆炸半径，批判性地思考安全性，确定漏洞值不值得修复，决定是否应该做实验。
为什么做实验对复杂系统来说，寻找做对的地方比寻找做错的地方信息量更大。故障往往来自系统内部的未知相互作用，靠预测很难提前发现。
混沌工程用实验去认识系统的真实属性：在受控条件下注入故障，观察系统怎么反应，把”我以为它会怎样”变成”它实际怎样”。知道了这些，团队才能用测试手段规避错误，让系统更有韧性。
冗余不是答案想让系统更健壮，一味加冗余只会掩盖问题。冗余本身也在引入复杂度：多一套副本，就多一套同步、切换、失败处理的逻辑，这些都是新的故障点。
比如给订单服务加一台备用节点，听起来更稳了。但故障演练时可能发现：切换逻辑要 40 秒才完成，业务早就超时了。冗余只是把”故障”变成了”没被验证过的故障”。
先想清楚再动混沌工程不是想做就做的实验。每一步都要回答：爆炸半径多大？会不会伤到真实用户？这个漏洞值得修吗？这次实验要验证什么假设？
这四件事想清楚了，再决定要不要在生产环境动手。
