1.7 测试计划

1.7.1 测试计划的概念

软件测试计划是一个规定了预先测试活动范围、途径、资源以及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。为了验证软件产品的可接受程度，可以编写测试计划文档。详细的测试计划文档可以帮助测试项目组之外的人了解为什么和怎样验证产品。

1.7.2 制定测试计划的好处

测试计划对于项目的推进是非常有好处的，主要体现在以下三个方面：

（1）项目经理、高层经理等相关领导能够根据测试计划做宏观调控，进行相应资源配置等。

（2）测试人员能够了解整个项目测试情况以及项目测试不同阶段所要进行的工作等。

（3）便于开发人员、市场人员、质量人员等了解测试人员的工作内容，进行相关配合工作。

1.7.3 测试计划制定人员

由具有丰富经验的项目测试负责人来制定测试计划，并且对整个测试过程负责。

1.7.4 测试计划的制定时间

测试计划的制定越早越好，以便可以对整个项目有总体的测试规划，同时可以预留出充足的时间以应对可能出现的风险。

1.7.5 测试计划的要素

测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况。测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太详细。一般要从以下几个方面来编写测试计划。

• Why：为什么要进行这些测试，测试目的是什么。

• What：测试哪些方面，确定测试的内容。

• When：测试不同阶段的起止时间，确定各测试活动的时间。

• Where：相应文档及缺陷的存放位置，测试环境等。

• Who：谁来负责相应的工作。

• How：如何去做，使用哪些测试工具以及哪些测试方法、测试策略进行测试。

1.7.6 测试计划模板

根据上面提到的测试计划的内容，我们制定出公司写测试计划的模板。软件测试计划模板的主要内容如下。

①测试目的。

②测试项目简介。

③测试参考文档。

④测试提交文档。

⑤术语和定义。

⑥测试策略。

⑦测试内容。

⑧资源。

⑨测试进度。

⑩测试人员的任务分配。

⑪风险和问题。

1.7.7 测试计划维护与评审

测试计划制定后，并不是一成不变的。软件需求、软件开发、人员等都可能随时发生变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求。

1.7.8 软件风险

1.软件风险管理的概念

软件风险（软件项目风险的简称）是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。软件风险管理试图以一种可行的原则和实践，规范化地控制影响项目成功的风险。

2.风险管理的重要性

有效的风险管理可以增加项目成功的机会，减少项目失败的概率。风险管理可以增加团队的稳固性。风险管理可以帮助项目经理抓住工作重点，将主要精力集中于重大风险，将工作方式从被动救火转变为主动防范。

3.软件项目的风险

软件项目的风险主要来源于需求、技术、成本和进度。

（1）需求风险

已经纳入的需求在继续变更；需求定义不准确，进一步的定义会扩展项目范畴；增加额外的需求；产品定义含糊的部分比预期需要更多的时间；在设计需求时客户参与不够；缺少有效的需求变化管理过程。

（2）计划编制风险

计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；计划是优化的，是“最佳状态”，但计划不现实，只能算“期望状态”；计划依赖特定的小组成员，而那个特定的小组成员其实指望不上；产品规模（代码行数、功能点、与前一产品规模的百分比）比估计的要大；完成目标日期提前，但没有相应地调整产品范围或可用资源；涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。

（3）组织和管理风险

仅由管理层或市场人员进行技术决策，导致计划进展缓慢，计划时间延长；低效的项目组结构使生产率降低；管理层审查决策的周期比预期的时间长；预算削减，打乱项目计划；管理层做出了打击项目组织积极性的决定；缺乏必要的规范，导致工作失误与重复工作；非技术的第三方的工作（预算批准、设备采购批准、法律方面的审查、安全保证等）时间比预期延长。

（4）人员风险

作为先决条件的任务（如培训及其他项目）不能按时完成；开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；缺乏激励措施，士气低下，降低了生产能力；某些人员需要更多的时间适应还不熟悉的软件工具和环境；项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性，没有找到项目急需的具有特定技能的人。

（5）开发环境风险

设施未及时到位，或设施虽到位，但不配套，如没有电话、网线、办公用品等；设施拥挤、杂乱或者破损；开发工具未及时到位；开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；新的开发工具的学习期比预期的长，内容繁多。

（6）客户风险

客户对于最后交付的产品不满意，要求重新设计和重做；客户的意见未被采纳，造成产品最终无法满足客户要求，因而必须重做；客户对规划、原型和规格的审核决策周期比预期的要长；客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；客户答复的时间（如回答或澄清与需求相关问题的时间）比预期长；客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。

（7）产品风险

矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；开发额外的不需要的功能，影响了计划进度；严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；开发一种全新的模块，比预期花费更长的时间；依赖正在开发中的技术，影响计划进度。

（8）设计和实现风险

设计质量低下，导致重复设计；一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；过高估计了增强型工具对计划进度的节省量；分别开发的模块无法有效集成，需要重新设计或制作。

（9）过程风险

大量的纸面工作导致进程比预期的慢，前期的质量保证行为不真实，造成后期的重复工作；太不正规（缺乏对软件开发策略和标准的遵循），导致沟通不足，质量欠佳，甚至需重新开发；过于正规（教条地坚持软件开发策略和标准），导致过多耗时于无用的工作；向管理层撰写进程报告占用开发人员的时间比预期的多；风险管理粗心，导致未能发现重大的项目风险。

4.风险管理

风险管理的主要操作步骤如下：

（1）风险管理计划制定。

（2）风险识别。

（3）风险定性分析。

（4）风险定量分析。

（5）风险应对计划制定。

（6）风险监控。

5.风险识别

风险识别是风险管理的重要一步，也是风险管理的基础，主要内容包括：确定风险的来源、风险产生的条件，描述风险特征。

风险识别的主要方法：头脑风暴法、面谈、Delphi问卷法、核对表、SWOT。