软件测试的组织与管理计划

开篇：润墨网以专业的文秘视角，为您筛选了一篇软件测试的组织与管理计划范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

中图分类号：TP 文献标识码：A 文章编号：1007-0745（2013）06-0140-01

作为软件的重要环节，软件测试越来越受到人们的重视。随着软件开发规模的增大、复杂程度的增加，以寻找软件中的错误为目的的测试工作就显得更加困难。然而，为了尽可能多地找出中的错误，生产出高的软件产品，加强对测试工作的组织和管理就显得尤为重要。

从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可作相对较强。但是，由于测试的依据是规格说明书、文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。软件的生命周期可用图1的表示。

为了确保软件的质量，对图1的过程应进行严格的管理。虽然测试是在实现且证后进行的，实际上，测试的准备工作在分析和设计阶段就开始了。

软件测试计划作为软件项目计划的子计划，在项目启动初期是必须规划的。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中，这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此也成为测试工作的赖于展开的基础。

一个好的测试计划可以起到如下作用

1. 避免测试的“事件驱动”

2. 使测试工作和整个开发工作融合起来

3. 资源和变更事先作为一个可控制的风险项目经理圈子

测试计划的模板在各个公司中都大同小异，在个人实践中发现，测试计划制定中存在的问题具有相似，下面重点就这些相似的问题谈谈如何制定软件项目测试计划。

问题一：测试阶段划分

就通常软件项目而言，基本上采用“瀑布型开发方式，这种开发方式下，各个项目主要活动比较清晰。整个项目生命周期为需设计编测试实施维护。然而，在制定测试计划时候，有些测试经理对测试的阶段划分还不是十分明晰，经常*遇到的问题是把测试单纯理解成系统测试，或者把把各类型测试设计（测试用例的编写和测试数据准备）全部放入生命周期的“测试阶段”，这样造成的问题是浪费了开发阶段可以并行的项目日程，另一方面造成测试不足。

相应阶段可以同步进行相应的测试计划编制，而测试设计也可以结合在开发过程中实现并行，测试的实施即执行测试的活动即可连贯在开发之后。值得注意的是：单元测试和集成测试往往由开发人员承担，因此这部分的阶段划分可能会安排在开发计划而不是测试计划中。

问题二：系统测试阶段日程安排

划分阶段清楚了，随之而来的问题是测试执行需要多长的时间？标准的工程方法或CMM方式是对工作量进行估算，然后得出具体的估算值。但是这种方法过于复杂，可以另辟专题讨论。一个可作的简单方法是：根据测试执行上一阶段的活动时间进行换算，换算方法是与上一阶段活动时间1：1.1～1.5左右。举个例子，对测试经理来说，因为开发计划可能包含了单元测试和集成测试，系统测试的时间大概是编*阶段（包含单元测试和集成测试）1到1.5倍。这种方法的优点是简单，依赖于项目计划的日程安排，缺点是水分太多，难于量化。那么，可以采用的另一个简单方法是经验评估。评估方法如下：项目管理者联盟文章

1. 计算需求文档的页数，得出系统测试用例的页数

需求页数：系统测试用例页数≈ 1：1

2. 由系统测试用例页数计算编写系统测试用例时间转自项目管理者联盟

编写系统测试用例时间≈系统测试用例页数×1小时

3. 计算执行系统测试用例时间

编写系统用例用时：执行系统测试用时≈ 1：

4. 计算回归测试包含的时间项目经理博客

系统测试用时：回归测试用时≈ 2：1

注：以上比值是个人工程经验值，需要更正比值的测试经理可以在具体实践中收集数据

基于以上方法优点是需求为已知的，可以利用已知来推算未知，适用于需求是已知且相对稳定的情况下；缺点是处于研发状态的项目，需求不清晰的时候比较难计算。现套用一个例子加于说明：需求文档页数为500，系统测试用例页数推算为500，则编写系统测试用例时间为500小时，执行系统测试用例时间为1000小时，回归测试需要500小时，加起来总共为2000小时，按一天8小时计算，共计250个工作日/人；假如一个月为22个工作日，则共计约11人/月，即投入4个人需要3个月左右时间工作量完成。当然，这是系统测试需要的全部时间。根据测试阶段划分原则，设计用例时间可以和开发同步进行，只需在测试阶段中安排的时间为1500小时即4人2个月工作量。

项目管理培训

（测试经理在编写测试计划时候，测试进度中的计划开始/结束时间往往用如20050101-20051201的具体时间划分方式，这样引起的问题是当项目计划进行变更的时候，测试计划时间不得不随时调整，这种变更可能是频繁而琐碎的，可以替代的办法是取消这种方式，采用30工作日/2人或者2人月这种工作量记录方式，这样一来，只需在项目计划中跟踪阶段的具体开始时间即可，不必反复修改测试计划。）

项目管理培训

值得注意的是：国内大多数公司的测试时间都是不足的，不可能按照这样的理想比例进行运作，因为测试执行的时间实际上不可能占据整个项目周期的1/2，甚至要短于其中任何一个项目阶段时间。即使是微软的测试结束原则也并不是完成所有必需的测试，而是测试在按计划结束的那一天结束！在测试时间不足的情况下，可参考下面项目计划变更时的做法，因为计划变更也涉及到测试时间不足的情况。

参考文献：

[1]徐新海；林宇斐；易伟；；CPU-GPGPU异构体系结构相关技术综述[J]；计算机工程与科学；2009年S1期

[2]赵改善，孔祥宁，王于静，方伍宝，孙成龙；64位集群计算平台波动方程叠前深度偏移的性能优化[J]；勘探地球物理进展；2005年01期

[3]职燕；；基于ARM的PC104/PLUS处理器模块设计[J]；桂林电子科技大学学报；2008年04期