说明：该篇博客是博主一字一码编写的，实属不易，请尊重原创，谢谢大家！
接着上一篇博客继续往下写 ：https://blog.csdn.net/qq_41782425/article/details/103530057
文章目录
一、测试计划的定义与原则
1.测试计划的定义
- IEEE 829-1983 测试计划的定义及目的
√ 一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排以及任何偶发事件的风险。
√ 软件测试计划是指导测试过程的纲领性文档。计划可以统一认识，可以规划过程。
√ 测试计划包含了产品概述、测试区域/测试范围（测试项）、 测试目标（被测特征）、测试优先级、测试配置/测试资源<硬件、软件、人力、技术等>、测试周期、进度安排（测试任务、人员安排）、 测试策略、测试方法/途径、测试交流、风险分析、测试标准、需交付文档等内容。
2.测试计划进入与退出准则、责任人
| 测试计划进入准则 | 测试计划退出准则 | 测试计划责任人 |
|---|---|---|
| 项目需求文档建立 | 测试计划由项目组评审通过 | 测试负责人 |
3.测试计划的编写原则
- 为了做好软件测试计划，需要注意以下几个方面
√ 1、明确测试的目标，增强测试计划的实用性。
√ 2、坚持“5W”规则，明确内容与过程。
✰ What（做什么）
✰ Why（为什么做）
✰ When（何时做）
✰ Where（在哪里）
✰ How（如何做）
√ 3、采用评审和更新机制，保证测试计划满足实践需求
✰ 测试计划创建完毕后必须提交给由项目经理、开发经理、测试经理、市场 经理等组成的评审委员会审阅。
√ 4、测试计划中不要包含详细的测试技术指标、测试步骤和测试用例。
✰ 测试计划和测试详细规格、测试用例之间是战略和战术的关系。
4.测试计划的主要工作
- 确定测试资源
- 工作量估算、里程碑和进度安排
- 风险分析
- 制定测试策略
- 编写计划书
二、确定测试资源
1.测试资源的分类
2.测试资源的规划
- 软件测试项目所需的人员和要求在各个阶段是不同的。
√ 在初期，测试组长首先要介入进去，参与需求评审、确定测试需求和测试范围、制定测试策略和测试计划等。
√ 在测试前期，需要一些比较资深的测试设计人员、测试脚本或测试工具开发人员参与或负责软件测试需求的制定和分解、设计测试用例、开发测试脚本等工作。
√ 在测试中期，主要是测试的执行，测试人员的数量取决于测试自动化实现的程度。如果测试自动化程度高，人力的投入则不需要明显的增加：如果测试自动化程度低，对执行测试的人员要求就比较多了。
√ 在测试后期，资深的测试人员可以抽出部分时间去做新项目的准备工作。
三、工作量估算、里程碑和进度安排
1.测试工作量估计
1.1 怎么确定测试工作量
- 测试的工作量是根据测试范围、测试任务和开发阶段来确定的。
√ 团队工作效率越低，测试工作量越大。
√ 测试的质量要求越高，测试的工作量越大。
√ 不同的开发阶段的测试工作量的差异也较大。新产品第一个版本的测试的工作量要大一些，若后续版本功能增加加多，则后续版本测试量变大。
√ 编程质量越低，测试的工作量越大。
√ 程序复杂度越高，测试的工作量越大。
√ 之前测试的缺陷多且分布很广，测试工作量大。
√ 风险越多，等级越高，测试工作量越大。
√ 自动化程度越低，测试工作量越高。但是在很多情况下，测试自动化并不能大幅度降低工作量，因为测试脚本开发的工作量很大。
1.2 任务细分
-
工作分解结构表方法
√ 列出本项目需要完成的各项任务。
√ 对每个任务进一步细分，可进行多层次细分，直到不能细分为止。
√ 根据任务的层次给任务进行编号。 -
案例
1.3 测试工作量估算
- 案例
√ 考虑回归测试（如 2-3 轮）
✰ W= Wo+WoRl+WoR2+Wo*R3
▲ W 为总工作量，Wo 为一轮测试的工作量。
▲ 在代码质量相对较低的情况下，假定 Rl、R2、R3 的值分别为 80%、60%、40%，若一轮功能测试的工作量是 100 个人日，则总的测试工作量为 280 个人日。
▲ 如果代码质量高，一般只需要进行两轮的回归测试，Rl、R2 值也降为 60%、30%，则总的测试工作量为 190 个人日，工作量减少了 32%以上。
2.测试里程碑和进度安排
2.1 里程碑
- 一般一个里程碑标志着上一个阶段结束、下一个阶段开始，也就是定义当前阶段完成的标准（Entry Criteria）和下一个新阶段启动的条件或前提（Entry Criteria）。
2.2 里程碑的特点
-
里程碑具有很强的时序性，可以有层次（分为父里程碑、子里程碑等）。
-
不同类型的项目，里程碑可能不同。
-
不同规模项目的里程碑，其数量的多少不一样，里程碑可以合并或分解。
2.3 软件测试中常见的里程碑
- 测试计划签发、测试用例签发、自动测试脚本完成、功能测试完成、性能测试完成等。
2.4 进度安排
- 进度安排就是确定里程碑的起止点。
- 案例
| 任务 | 天 | 任务 | 天 | 任务 | 天 |
|---|---|---|---|---|---|
| M21：测试计划制定 | 11 | M26：测试开发 | 15 | M62：测试评估 | 3 |
| 确定项目 | 1 | 建立测试开发环境 | 1 | 评估测试需求的覆盖率 | 1 |
| 定义测试策略 | 2 | 录制和回放原型过程 | 2 | 评估缺陷 | 0.5 |
| 分析测试需求 | 3 | 开发测试过程 | 5 | 决定是否达到测试完成的标准 | 0.5 |
| 估算测试工作量 | 1 | 测试和调试测试过程 | 2 | 测试报告 | 1 |
| 确定测试资源 | 1 | 修改测试过程 | 2 | ||
| 建立测试结构组织 | 1 | 建立外部数据集 | 1 | ||
| 生成测试计划文档 | 2 | 重新测试并调试测试过程 | 2 | ||
| M23：测试设计 | 12 | M42：功能测试 | 9 | ||
| 测试用例的设计 | 7 | 设置测试系统 | 1 | ||
| 测试用例的审查 | 2 | 执行测试 | 4 | ||
| 测试工具的选择 | 1 | 验证测试结果 | 2 | ||
| 测试环境的设计 | 2 | 调查突发结果 | 1 | ||
| 生成缺陷日记 | 1 |
四、 测试风险分析与管理
对软件测试中的风险进行管理，基本内容有：风险识别、风险评估和风险控制。
1.风险识别
- 建立风险项目检查表，将测试范围、测试过程中的风险识别出来，按风险内容进行逐项检查、逐个确认，确定哪些是可避免的风险，哪些是不可避免的，对可避免的风险要尽量采取措施去避免。
- 案例
2.风险评估
从成本、进度及性能三个方面对风险进行评估，通过评估可以确定这些风险的特点或可能带来的危害，根据风险发生的概率和带来的影响确定风险的优先级。
3.风险控制
-
制定风险管理计划和风险应急处理方案，来降低风险和消除风险。
-
对风险的处理还要制定一些应急的、有效的处理方案。
-
做计划时，估算资源、时间、预算等要留有余地，不要用到 100%。
-
制定文档标准，并建立一种机制，保证文档及时产生。对所有工作多进行互相审查，及时发现问题。
-
案例
五、制定测试策略
1.什么是测试策略
-
描述当前测试项目的目标和所采用的测试方法；
-
描述在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到确认；
-
描述测试不同阶段（单元测试、集成测试、系统测试）的测试对象、范围和方法；
-
描述每个阶段内所要进行的测试类型（功能测试、性能测试、压力测试等）。
2.案例
- 分阶段的测试策略
√ 严格执行代码复查，保证在早期就发现问题，而非在代码发布之后。
√ 利用单元测试和集成测试，尽早地发现更多的问题，并准备好自动化测试的BVT （Build Verification Test，软件包验证测试）。
✰ BVT 是开发人员检入自己的代码，项目组编译生成当天的版本后进行的测试，主要目的是验证最新的软件版本在功能上是否完整，主要的软件特性是否正确实现。冒烟测试通过后，就可以进行更大规模的测试了。
✰ BVT 优点是时间短，缺点是覆盖率很低。BVT 测试也称“冒烟测试”。
√ 不能忽略安全性测试、可用性测试、配置测试和数据完整性测试。
√ 在功能性测试、安全性测试、配置测试中可进行一些探索性测试。
√ 制定更为详细的 UAT（用户验收测试）测试计划，将其与测试脚本和培训材料一起提供给用户，以帮助用户快速提高并完成任务。
六、 编写测试计划书
-
测试计划是一个过程，不仅仅是“测试计划书”这样一个文档，测试计划会随着情况变化不断进行调整，以便于优化资源和进度安排，减少风险，提高测试效率，并及时修改“测试计划书”。
-
测试计划书的内容也可以按集成测试、系统测试、验收测试等阶段去组织。
-
为每一个阶段制定一个计划书，还可以为每个测试任务，目的（安全性测试、性能测试、可靠性测试等）制定特别的计划书。
-
对于一些重要的项目，会形成一系列的计划书，如测试范围，风险分析报告、测试标准工作计划、资源和培训计划、风险管理计划、测试实施计划、质量保证计划等。
