测试计划

一、 测试计划的定义与原则

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 进度安排

进度安排就是确定里程碑的起止点。
案例

四、 测试风险分析与管理

对软件测试中的风险进行管理，基本内容有：风险识别、风险评估和风险控制。

1. 风险识别

• 建立风险项目检查表，将测试范围、测试过程中的风险识别出来，按风险内容进行 逐项检查、逐个确认，确定哪些是可避免的风险，哪些是不可避免的，对可避免的 风险要尽量采取措施去避免。

案例

2. 风险评估

从成本、进度及性能三个方面对风险进行评估，通过评估可以确定这些风险的特点或可 能带来的危害，根据风险发生的概率和带来的影响确定风险的优先级。

3. 风险控制

• 制定风险管理计划和风险应急处理方案，来降低风险和消除风险。
• 对风险的处理还要制定一些应急的、有效的处理方案。
• 做计划时，估算资源、时间、预算等要留有余地，不要用到 100%。
• 制定文档标准，并建立一种机制，保证文档及时产生。对所有工作多进行互相审查， 及时发现问题。
• 案例
  

五、 制定测试策略

1. 什么是测试策略

• 描述当前测试项目的目标和所采用的测试方法；
• 描述在规定的时间内哪些测试内容要完成，软件产品的特性或质量在哪些方面得到 确认；
• 描述测试不同阶段（单元测试、集成测试、系统测试）的测试对象、范围和方法；
• 描述每个阶段内所要进行的测试类型（功能测试、性能测试、压力测试等）。

2. 案例

分阶段的测试策略

• 严格执行代码复查，保证在早期就发现问题，而非在代码发布之后。
• 利用单元测试和集成测试，尽早地发现更多的问题，并准备好自动化测试的 BVT （Build Verification Test，软件包验证测试）。
  • BVT 是开发人员检入自己的代码，项目组编译生成当天的版本后进行的 测试，主要目的是验证最新的软件版本在功能上是否完整，主要的软件特 性是否正确实现。冒烟测试通过后，就可以进行更大规模的测试了。
  • BVT 优点是时间短，缺点是覆盖率很低。BVT 测试也称“冒烟测试”。
• 不能忽略安全性测试、可用性测试、配置测试和数据完整性测试。
• 在功能性测试、安全性测试、配置测试中可进行一些探索性测试。
• 制定更为详细的 UAT（用户验收测试）测试计划，将其与测试脚本和培训材 料一起提供给用户，以帮助用户快速提高并完成任务。

六、编写测试计划书

• 测试计划是一个过程，不仅仅是“测试计划书”这样一个文档，测试计划会随着情 况变化不断进行调整，以便于优化资源和进度安排，减少风险，提高测试效率，并 及时修改“测试计划书”。
• 测试计划书的内容也可以按集成测试、系统测试、验收测试等阶段去组织。
• 为每一个阶段制定一个计划书，还可以为每个测试任务，目的（安全性测试、性能 测试、可靠性测试等）制定特别的计划书。
• 对于一些重要的项目，会形成一系列的计划书，如测试范围，风险分析报告、测试 标准工作计划、资源和培训计划、风险管理计划、测试实施计划、质量保证计划等。