如何制定测试计划

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

1. 测试计划的定义

• • IEEE 829-1983 测试计划的定义及目的
    • 一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了 测试项、被测特征、测试任务、人员安排以及任何偶发事件的风险。
    • 软件测试计划是指导测试过程的纲领性文档。计划可以统一认识，可以规划过 程。
    • 测试计划包含了产品概述、测试区域/测试范围（测试项）、 测试目标（被测特征）、测试优先级、测试配置/测试资源<硬件、软件、人力、技术等>、测 试周期、进度安排（测试任务、人员安排）、 测试策略、测试方法/途径、测试交流、风险分析、测试标准、需交付文档等内容。

1. 测试计划进入与退出准则、责任人

测试计划进入准则	测试计划退出准则	测试计划责任人
项目需求文档建立	测试计划由项目组评审通过	测试负责人

1. 测试计划的编写原则

• • 为了做好软件测试计划，需要注意以下几个方面
    • 1、明确测试的目标，增强测试计划的实用性。
    • 2、坚持“5W”规则，明确内容与过程。
      • What（做什么）
      • Why（为什么做）
      • When（何时做）
      • Where（在哪里）
      • How（如何做）
    • 3、采用评审和更新机制，保证测试计划满足实践需求
      • 测试计划创建完毕后必须提交给由项目经理、开发经理、测试经理、市场 经理等组成的评审委员会审阅。
    • 4、测试计划中不要包含详细的测试技术指标、测试步骤和测试用例。
      • 测试计划和测试详细规格、测试用例之间是战略和战术的关系。

1. 测试计划的主要工作

• • 确定测试资源
  • 工作量估算、里程碑和进度安排
  • 风险分析
  • 制定测试策略

• • 编写计划书

二、 确定测试资源

1. 测试资源的分类

1. 测试资源的规划

• • 软件测试项目所需的人员和要求在各个阶段是不同的。
    • 在初期，测试组长首先要介入进去，参与需求评审、确定测试需求和测试范围、 制定测试策略和测试计划等。
    • 在测试前期，需要一些比较资深的测试设计人员、测试脚本或测试工具开发人 员参与或负责软件测试需求的制定和分解、设计测试用例、开发测试脚本等工 作。
    • 在测试中期，主要是测试的执行，测试人员的数量取决于测试自动化实现的程 度。如果测试自动化程度高，人力的投入则不需要明显的增加：如果测试自动 化程度低，对执行测试的人员要求就比较多了。
    • 在测试后期，资深的测试人员可以抽出部分时间去做新项目的准备工作。

三、 工作量估算、里程碑和进度安排

1. 测试工作量估计

1. 1. 怎么确定测试工作量

• 测试的工作量是根据测试范围、测试任务和开发阶段来确定的。
  • 团队工作效率越低，测试工作量越大。
  • 测试的质量要求越高，测试的工作量越大。

• • 不同的开发阶段的测试工作量的差异也较大。新产品第一个版本的测试的工作 量要大一些，若后续版本功能增加加多，则后续版本测试量变大。
  • 编程质量越低，测试的工作量越大。
  • 程序复杂度越高，测试的工作量越大。
  • 之前测试的缺陷多且分布很广，测试工作量大。
  • 风险越多，等级越高，测试工作量越大。
  • 自动化程度越低，测试工作量越高。但是在很多情况下，测试自动化并不能大 幅度降低工作量，因为测试脚本开发的工作量很大。

1. 1. 任务细分

• 工作分解结构表方法
  • 列出本项目需要完成的各项任务。
  • 对每个任务进一步细分，可进行多层次细分，直到不能细分为止。
  • 根据任务的层次给任务进行编号。

案例

1. 1. 测试工作量估算

• 案例
  • 考虑回归测试（如 2-3 轮）
    • W= Wo+Wo*Rl+Wo*R2+Wo*R3
      1. W 为总工作量，Wo 为一轮测试的工作量。
      2. 在代码质量相对较低的情况下，假定 Rl、R2、R3 的值分别为 80%、60%、40%，若一轮功能测试的工作量是 100 个人日，则总的测试工作量为 280 个人日。
      3. 如果代码质量高，一般只需要进行两轮的回归测试，Rl、R2  值也降为 60%、30%，则总的测试工作量为 190 个人日，工作量减少了 32% 以上。

1. 测试里程碑和进度安排

1. 1. 里程碑

• 一般一个里程碑标志着上一个阶段结束、下一个阶段开始，也就是定义当前阶段完

成的标准（Entry Criteria）和下一个新阶段启动的条件或前提（Entry Criteria）。

1. 1. 里程碑的特点

• 里程碑具有很强的时序性，可以有层次（分为父里程碑、子里程碑等）。
• 不同类型的项目，里程碑可能不同。
• 不同规模项目的里程碑，其数量的多少不一样，里程碑可以合并或分解。

1. 1. 软件测试中常见的里程碑

• 测试计划签发、测试用例签发、自动测试脚本完成、功能测试完成、性能测试完成 等。

1. 1. 进度安排

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

任务	天	任务	天	任务	天
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. 风险识别

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

案例

1. 风险评估

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

1. 风险控制

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

五、 制定测试策略

1. 什么是测试策略

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

1. 案例

• • 分阶段的测试策略
    • 严格执行代码复查，保证在早期就发现问题，而非在代码发布之后。
    • 利用单元测试和集成测试，尽早地发现更多的问题，并准备好自动化测试的

BVT （Build Verification Test，软件包验证测试）。

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

六、 编写测试计划书

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