目录
一、软件测试的原则
（1）原则类别
（2）原则详解
二、软件测试模型
（1）模型类别
（2）模型详解
（3）图解：V 模型
（4）图解：W 模型
（5）图解：H 模型
（6）图解：敏捷测试模型
一、软件测试的原则
（1）原则类别
（2）原则详解
| 术语 | 属性 | 描述 | 备注 |
|---|---|---|---|
| 软件测试的原则 | 溯源性原则 | 对需求的符合性验证和确认来体现总目标 “保证软件质量”，因此测试应当溯源到原始需求 | |
| 工程性原则 | 测试需要贯穿软件生产的各阶段，需要以工程化的思想和方法来组织和实施 | ||
| 独立性原则 | 避免开发工程师自己测试自己的程序，企业需要设立独立的测试工程师岗位或测试部门去承担测试工作 | 为了避免长时间的合作造成测试和开发的同化，从而慢慢丧失测试的独立性原则，应当在遵循独立性的原则同时，注重交叉性，即大企业可以进行互换项目的开发或测试。 | |
| 合理性原则 | 在有限时间和有限资源时不可能做到完全穷举式测试，因此需要合理地设定测试的终止条件 | ① 测试成本与测试强度成正比 ② 遗留缺陷与测试强度成反比 ③ 正确策略：在质量要求和测试强度之间寻找合理的结合点，获得最优的测试消费比，避免测试不足和过度测试 | |
| 不完全性原则 | 任何人或者机构对软件测试后的评价只能描述为“未发现错误”，而不能描述为“没有错误” | ① 不管强度有多大，测试都不能暴露全部的缺陷，这是测试自身决定了的。 ② 测试能做的是尽可能多地发现错误，而不能证明软件不再包含错误。 | |
| 相关性原则 | 缺陷常常有聚集现象，测试工程师对暴露错误多的模块应加强测试 | 一个软件（模块）中被找到的缺陷越多，则这个软件（模块）中残留的缺陷也越多 | |
| 可接受性原则 | 在各方面可以接受的前提下，对于已发现的缺陷，由恰当的人员进行决策后，可以允许某些缺陷遗留在软件中 | ① 测试的直接目标：发现软件缺陷 ② 测试的进一步目标：修复发现的缺陷 ③ 修复缺陷需要代价，由于时间或修复风险等方面的原因，已发现的缺陷不一定全部修复 | |
| 风险性原则 | 鉴于测试的合理性原则，测试实际上是对软件进行采样测试，采样必然存在风险 | 测试虽然是为了降低或化解软件的质量风险，但必须认识到测试本身也是有风险的 |
二、软件测试模型
（1）模型类别
（2）模型详解
| 术语 | 属性 | 描述 | 备注 |
|---|---|---|---|
| 软件测试模型 | V 模型 | ① 目标：发现缺陷 ② 测试成了阶段性的工作 ③ 最典型的活动：V&V ④ 局限性：是在编码结束之后才开始的，不符合尽早开始测试的原则，缺陷修复代价大；高度依赖与开发的瀑布模型，不能适用所有的软件项目 | 对应开发的瀑布模型 |
| W 模型 | ① 目标：保证软件质量 ② 分布于软件测试过程的每一个阶段 ③ 修复了 V 模型的局限性：充分体现尽早开展测试的原则 ④ 局限性：高度依赖与开发的瀑布模型，不能适用所有的软件项目 | ① W 是两个 V 的叠加，一个描述开发过程，一个描述测试过程 ② 测试的对象不仅仅只是程序，还包括各个阶段的文档和数据 | |
| H 模型 | ① 改善 W 模型的一些问题：兼顾测试的效率和灵活性，适合各种规模及类型的软件项目 ② 把测试活动从软件开发过程中独立出来，只要测试条件满足即开展测试 | 充分反映了每一个测试的完整活动，包括测试准备和测试执行 | |
| 敏捷测试模型 | ① 敏捷测试是敏捷开发的组成部分 ② 需要时刻与项目其他人员保持紧密协作，时刻关注需求变化并实施测试，以体现测试的时效性和适应性 | 敏捷测试源于敏捷开发 | |
| TMMi 测试成熟度模型集成模型 | 关注软件测试过程改进的模型 | ||
| TPI 测试过程改进模型 | 关注软件测试过程改进的模型 | ||
| CTP 关键测试过程模型 | 关注软件测试过程改进的模型 | ||
| STEP 系统化测试和评估过程模型 | 关注软件测试过程改进的模型 |
