软件测试基础
从定义、目标、verification 与 validation、testing 与 QA 区分，到七大原则，理解软件测试的底层哲学。
#type / concept
#status / growing
#tech / dev / test
[!info] related notes
- 所属 MOC: Testing MOC
- 并列概念: 软件测试过程与治理, 测试设计技术
- 关系笔记: Monorepo 测试架构, TDD 中测什么与测试金字塔
软件测试基础
一句话定义
测试不是开发后面的一道关卡，而是一套贯穿需求、设计、编码、集成、发布、运行的风险控制与反馈系统。
测试到底是什么
如果把软件工程里的测试压缩成一句话，它更接近：
- 发现缺陷
- 评估工作产品质量
- 帮助发布和风险决策
- 给团队提供真实反馈
所以测试不只是“执行几条 case 看绿不绿”，也不是“证明系统绝对没问题”，而是在有限成本下最大化我们对质量和风险的已知信息。
verification 与 validation
测试同时服务于两件事：
- verification：系统是否满足规格、设计和约束
- validation：系统是否在真实环境里满足用户和业务需要
这也是为什么“规格都过了”并不自动等于“产品真的有价值”。
testing 和 QA 不是一回事
这两个词经常被混用，但关注点不同：
- testing 更偏产品导向，强调发现问题、控制质量、提供反馈
- QA 更偏过程导向，强调预防问题、改进流程、降低系统性失误
更成熟的团队不会把两者对立起来，而是让 testing 和 QA 分别承担产品反馈与过程改进。
软件测试的七条核心原则
1. 测试只能证明缺陷存在，不能证明绝对无缺陷
测试的结果是降低未知风险，不是宣告系统完美。
2. 穷举测试几乎不可能
输入组合、状态空间和环境变量通常都太大，所以测试必须做取舍。
3. 越早测试通常越省钱
需求、设计和代码越早暴露问题，修复成本通常越低。
4. 缺陷往往集中在少量模块
高复杂度、高变更频率、高历史缺陷密度的区域更值得重点测试。
5. 同一批测试反复运行会逐渐失效
如果测试集长期不变，它对新风险和新变化的探测能力会下降。
6. 测试强烈依赖上下文
不同系统、风险、团队、监管要求和业务场景，都会改变测试策略。
7. 规格全过也可能造出错误产品
如果系统满足文档，却没有满足用户真实需求，测试工作依然不算完成。
测试真正服务什么
测试的价值不只体现在“抓 bug”，它还服务于：
- 需求澄清
- 架构验证
- 发布决策
- 风险沟通
- 回归保护
- 流程改进
换句话说，测试既是质量活动，也是信息活动。
为什么这层基础很重要
如果团队把测试理解成“开发做完后的最后一道检查”，就很容易出现这些问题：
- 需求阶段没人思考可测性
- 设计阶段没人考虑边界与观测点
- 编码阶段没人建立回归保护
- 发布后问题没有回流成新的测试资产
而一旦把测试看成反馈系统，很多工程决策都会改变。
最短记忆方式
测试的目标不是证明软件完美，而是在有限成本下尽可能看清质量和风险。