测试可靠性
预测信息准确的前提：
- 系统完全没有改变
- 充分描述整个系统的改变
测试是一个用来证明变更前系统的某些领域相等的手段。
软件测试的类型
- 传统测试
- 生产测试
传统测试
- 单元测试
- 集成测试
- 系统测试
- 冒烟测试
- 性能测试
- 回归测试
每个测试都有成本，通常来说单元测试时间成本低 如果要将完整的功能架设起来测试，通常需要几个小时。关注测试成本，是软件提升效率的重要因素。
生产测试
生产测试和一个已经部署在生产环境的业务系统直接交互，而不是运行在封闭的测试环境。有时候称为黑盒测试
- 配置测试
- 压力测试
- 金丝雀测试
- 一小部分机器先升级，保持一定的孵化期。
- 将代码置于比较难以预测的用户流量下
- 需要能够快速的回滚
创造一个构建和测试环境
- 测试的重点集中在用最小力气得到最大收益的地方
- 划分优先级
- 寻找关键函数关键类
- 寻找提供给其他团队的 API
- 发布前，通过冒烟测试
- 寻找到的 bug 变成测试用例
- 建立良好的测试基础设施
- 追踪代码变更
- 每次代码改变就进行构建
- 精确的构建，只构建修改的地方，并执行修改代码的单侧
- 使用工具可视化或者量化测试覆盖度
- 和钱相关的系统需要更多测试
大规模测试
单元测试需要有针对性的覆盖组件中相互依赖的部分
测试大规模使用的工具
针对灾难的测试
灾难恢复工具被精心设计为离线运行
- 计算出一个可记录状态，等同于服务完全停止的状态
- 将可记录的状态推送给非灾难验证工具
- 支持常见的发布安全边界检查
对速度的渴求
有的时候测试的结果会在重复运行下发生改变。所以需要针对某些场景，重复运行一定数量的测试。
发布到生产环境
通常，生产环境的配置文件容易被测试忽略。
集成
使用解释性语言编写配置文件是有风险的。程序的执行时间没有上限，需要加入截止时间检查。
使用成熟的语法（YAML）和大量测试的解析器。
生产环境探针
测试机制是对确定的数据检验系统行为是否可以接受。 监控机制择时在未知数据输入下系统行为是否可以接受。
已知的正确请求应该成功，已知的错误请求应该失败。重放已知请求观察系统是否正常。
（感觉应该是书翻译的问题所谓的探针应该是 mock 服务。mock 服务部署在生产环境 。在确定的入参下，有确定的返回值。调用方可以使用这个探针进行测试）
小结
测试是工程师提高可靠性投入回报比较高的手段。
