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

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（用户验收测试）测试计划，将其与测试脚本和培训材 料一起提供给用户，以帮助用户快速提高并完成任务。

六、编写测试计划书

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

                           《图书管理系统》

一、简介
1．目的
为了验证图书管理系统的图书管理模块能否正常实现，以图书管理系统作为测试对象，展开系统测试。
2．背景
图书管理系统包括图书录入、图书修改、图书删除、图书查询等九个子系统，用于管理图书馆日常运作的整个过程。各子系统所处理的业务前后衔接，数据共享。

3．范围
1.图书管理模块

二、测试需求
1.数据库测试；
2.功能性测试；
3.性能测试；

三、测试风险
1.质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始
终测试不到或验证的标准不对。
2.测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏。
3.需求的临时或突然变化，导致设计的修改和代码的重写，测试时间不够。
4.测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等。
5.测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差。
6.有些缺陷出现频率不是百分之百，不容易被发现；如果代码质量差，软件缺陷很
多，被漏检的缺陷可能性就大。
前面三种风险是可以避免的，而 4～6 的四种风险是不能避免的，可以降到最低。最后
一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。
针对上述软件测试的风险，有一些有效的测试风险控制方法，如：
测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员53
按已列出条目逐条检查。
有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的
低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这
个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对
策是去掉那个新功能，转移这种风险。
有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，
我们就要通过提高测试用例的覆盖率（如达到 99.9%）来降低这种风险。
为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的
处理还要制订一些应急的、有效的处理方案。

四、测试策略
1.数据和数据库完整性测试
数据库和数据库进程应作为<项目名称>中的子系统来进行测试。在测试这些子系统时，
不应将测试对象的用户界面用做数据的接口。对于数据库管理系统（DBMS），还需要进行
深入的研究，以确定可以支持以下测试的工具和方法。数据库测试如表 2-2 所示。
表 2-2 数据库测试说明

发布文章的话表格不能直接复制到上面（下边那些有的， 都是带表格的是表格里的数据），想要带有表格的标准格式就下载一下我发布过的资源，软件测试——图书管理系统的测试计划书吧

测试目标
确保数据库访问方法和进程正常运行，数据不会遭到损坏。
方法
 调用各个数据库访问方法和进程，并在其中填充有效的和无效
的数据或对数据的请求。
 检查数据库，确保数据已按预期的方式填充，并且所有数据库
事件都按正常方式出现：或者检查所返回的数据，确保为正当
的理由检索到了正确的数据：
完成标准 所有的数据库访问方法和进程都按照设计的方式运行，数据没有遭
到损坏。

需考虑的特殊事项
 测试可能需要 DBMS 开发环境或驱动程序以便在数据库中直
接输入或修改数据、
 进程应该以手工方式调用。
 应使用小型或最小的数据库（其中的记录数很有限）来使所有
无法接受的事件具有更大的可见性。

2.功能测试
测试对象的功能测试应该侧重于可以被直接追踪到用例或业务功能和业务规则的所有
测试需求。这些测试的目标在于核实能否正确地接受、处理和检索数据以及业务规则是否正
确实施。这种类型的测试基于黑盒方法，即通过图形图书管理界面与应用程序交互并分
析输出结果来验证应用程序及其内部进程。表 2-3 列出的是每个应用程序推荐的测试方法概
要。
表 2-3 功能测试说明表

测试目标 确保测试对象的功能正常，其中包括数据添加、修改、删除和查询。
方法 利用有效的和无效的数据来执行各个用例、用例流或功能，以核实
以下内容：
 在使用有效数据时得到预期的结果。
 在使用无效数据时显示相应的错误消息或警告消息。
 各业务规则都得到了正确的应用。
完成标准
 所计划的测试已全部执行。
 所发现的缺陷已全部解决。
需考虑的特殊事项
确定或说明那些将对功能测试的实施和执行造成影响的事项或因素
（内部的或外部的)。

3.性能评价
性能评价是一种性能测试，它对响应时间、事务处理速率和其他与时间相关的需求进行
评测和评估。性能评价的目标是核实性能需求是否都已满足。实施和执行性能评价的目的是
将测试对象的性能为当做条件（如工作量或硬件配置）的一种函数来进行评价和微调。性能
测试如表 2-6 所示。
注：以下事务均指“逻辑业务事务”。这种事务被定义为将由系统的某个主角通过使用
测试对象来执行的特定用例，例如，添加或修改某个合同。
表 2-6 性能测试说明表

测试目标
核实所指定的事务或业务功能在以下情况下的性能行为：
 正常的预期工作量。
 预期的最繁重工作量。

方法
使用为功能或业务周期测试制定的测试过程。
通过修改数据文件来增加事务数量，或通过修改脚本来增加每项事
务的迭代次数。
脚本应该在一台计算机上运行（最好是以单个用户、单个事务为基
准），并在多台客户机（虚拟的或实际的客户机，请参见下面的“需
考虑的特殊事项”）上重复。

完成标准  单个事务或单个用户：在每个事务所预期或要求的时间范围内
成功地完成测试脚本，没有发生任何故障。
 多个事务或多个用户：在可接受的时间范围内成功地完成测试
脚本，没有发生任何故障。
需考虑的特殊事项
综合的性能测试还包括在服务器上添加后台工作量。
可采用多种方法来执行此操作，其中包括：
直接将“事务强行分配到”服务器上，这通常以“结构化查询
语言”(SQL）调用的形式来实现。
通过创建“虚拟的”用户负载来模拟许多个（通常为数百个）56
客户机。此负载可通过“远程终端仿真”（Remote Terminal Emulation）
工具来实现。此技术还可用于在网络中加载“流量”。
使用多台实际客户机（每台客户机都运行测试脚本）在系统上
添加负载。
性能测试应该在专用的计算机上或在专用的机时内执行，以便
实现完全的控制和精确的评测。
性能测试所用的数据库应该是与实际大小相同或等比例缩放的
数据库。

五、测试工具
此项目将使用表 2-14 所示的工具。
注：可以视情况删除或添加项目。
表 2-14 测试工具
工具 厂商 版本

测试管理 Quality Center HP
10.0

功能性测试
QTP
HP
12.0

性能测试
LoadRunner
HP
12.0

六、资源
1.人力资源
表 2-15 列出了在此项目的人员配备方面所做的各种假定。
表 2-15 人力资源说明表

人力资源
角色
推荐的最少资源 具体职责或注释

测试组长
1 负责拟订软件项目的测试计划和方案，提供
测试技术指导，组织测试资源，安排测试计
划实施，提交测试分析报告，总结整个测试
活动。

测试设计员 1 参与制订测试计划，生成测试模型，在面向
对象的设计系统中确定并定义测试类的操
作、属性和关联关系。
确定测试用例，指导测试实施，参与测试评
估和测试分析报告的编写。
测试员
1 执行实施测试，填写测试记录，记录结果和
缺陷。

2.系统资源
表 2-16 列出了测试项目所需的系统资源。
此时并不完全了解测试系统的具体元素。建议让系统模拟生产环境，并在适当的情况下
减小访问量和数据库大小。

表 2-16 系统资源说明表

系统资源
服务器名 172.16.112.177
数据库名 sa
客户端测试 PC 172.16.112.177

七、测试进度和里程碑
1.项目测试进度
以下测试工作任务的起止时间为：
① 图书录入功能
② 图书修改功能
③ 图书删除功能
④ 图书查询功能

2.测试里程碑
对<项目名称>的测试应包括上面各节所述的各项测试的测试活动。应该为这些测试确
定单独的项目里程碑，如表 2-17 所示，以通知项目的状态和成果。
表 2-17 测试里程碑说明表
里程碑任务 工作量 开始日期 结束日期
图书录入功能
图书修改功能
图书删除功能
图书查询功能

八、可交付工件
这部分内容列出了将要创建的各种文档、工具和报告，及其创建人员、交付对象和交付时间。例如，测试计划说明书、测试用例或测试脚本、开发的测试工具、测试日志、缺陷报
告、测试分析报告、测试总结等。
（1）概述
① 测试目的
提供一个对项目软件进行测试的总体安排和进度计划，确定现有项目的信息和应测试的
软件标明推荐的测试需求（高层次）和可采用的测试策略，并对这些策略加以说明确定所需
的资源，并对测试的工作量进行估计，列出测试项目的可交付元素。
② 测试范围
描述测试的各个阶段，例如，单元测试、集成测试或系统测试，并说明本计划所针对的
测试类型（如功能测试或性能测试)。简要地列出测试对象中将接受测试或将不接受测试的
些特性和功能。
如果在编写此文档的过程中做出的某些假设可能会影响测试设计、开发或实施，则列出
所有这些假设。列出可能会影响测试设计、开发或实施的所有风险或意外事件。列出可能会
影响测试设计、开发或实施的所有约束。
③ 限制条件
a. 设备所用到的设备类型、数量和预定使用时间。
b. 软件列出将被用来支持本项测试过程而本身又并不是被测软件的组成部分的软件，
如测试驱动程序、测试监控程序、仿真程序、桩模块等。
c. 列出在测试工作期间预期可由用户和开发任务组提供的工作人员的人数。技术水平
及有关的预备知识，包括一些特殊要求，如倒班操作和数据输入人员。
④ 参考文档
列出制作此测试计划所依据的文档，例如，需求规约、设计规约，概要或详细设计、业
务流程、数据流程等。列出要用到的参考资料。
（2）测试摘要
① 测试目标
② 资源和工具
a. 资源
项目使用的资源，及其主要职责、知识或技能。
b. 工具
列出测试所使用的测试工具或自主开发的测试软件，说明运用这些工具或开发软件测试
对象的何种特性。
③ 送测要求
④ 测试种类
（3）测试风险
（4）暂停标准和再启动要求
（5）测试任务和进度
列出要测试中的每一项测试内容，例如：
模块功能测试；
接口正确性测试；
数据文件存取的测试；
运行时间的测试；
设计约束和极限的测试等。
并针对每项测试内容给出测试条件，如：
所用到的设备、数量和预定使用时间；
给出对这项测试的进度安排，包括进行测试的日期和工作内容（如熟悉环境、培训、准
备输入数据等）。
（6）测试提交物
① 测试计划
② 测试用例
③ 缺陷记录
④ 测试总结