软件测试计划

软件测试计划

软件测试计划 篇1

1.1目的

简述本计划的目的，旨在说明各种测试阶段任务、人员分配和时间安排、工作规范等。

测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。在计划目的中需要指明读者对象。

1.2名词解释

列出本计划中使用的专用术语及其定义

列出本计划中使用的全部缩略语全称及其定义

缩写 词或术语	英文解释	中文解释

1.3参考资料

列出本计划各处参考的经过核准的全部文档和主要文献。

1.4测试摘要

这一节主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员(比如经理或开发项目的负责人)。

1.4.1 重点事项

列出测试的重点事项。可以将问题按重要程度和优先级罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在

1.4.2 争议事项

简要说明争议事项。

1.4.3 风险评估

通过对技术文档的阅读，对被测系统可能存在的问题：系统设计，数据库设计，响应时间，计费策略，因测试环境不足可能存在的测试缺陷事先评估出来，以指导测试方案，进行有重点的测试.

1.4.4 时间进度

简要说明测试开始时间与发布时间。

1.4.5 测试目标

简要说明测试发布的质量目标：

测试计划中所有测试方法和模块已经执行通过

所有的测试案例已经执行过

所有的重要等级为1/2的Bug已经解决并由测试验证

第2章 项目背景

2.1测试范围

说明本计划涵盖的测试范围，比如功能测试、集成测试、系统测试、验收测试等。通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些问题后，测试人员对该做什么有一个清晰的认识。

(1)简要地列出测试对象中将接受测试或将不接受测试的那些性能和功能。

(2)如果在编写此文档的`过程中作出的某些假设可能会影响测试设计、开发或实施，则列出所有这些假设。

(3)列出可能会影响测试设计、开发或实施的所有风险或意外事件。

(4)列出可能会影响测试设计、开发或实施的所有约束。

提示和技巧：

需要测试和特别注意测试那些部分?

测试是否专么针对与某些问题的解决?

哪些部分不需要测试，为什么?

哪些部分需要推迟测试,为什么?

是否要验证每个模块的稳定性?

测试的优先级和先后顺序

2.2测试目标

系统目标对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。

通常情况下项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。

2.3联系方式

列出项目参与人员的职务、姓名、E-mail 和电话。

职务	姓名	E-Mail	电话
开发工程师
CVS Builder
开发经理
测试负责人
测试人员

2.4风险及约束

列出测试过程中可能存在的一些风险和制约因素，并给出规避方案。如：

由于客观存在的设备、网络等资源原因，使得测试不全面。明确说明哪些资源欠缺，产生什么约束

由于研发模式为现场定制，且上线时间压力大，使得测试不充分。明确说明在此中约束下，测试如何应对

只针对专门的客户群需求的测试。明确说明此约束下的客户群和业务范围。

2.5测试文档

列出测试过程中可能用到的参考文档、相关的设计文档以及保存位置，测试完成后应产生的文档。

2.5.1测试参考文档

文档说明	作者	文档位置（CVS）
需求文档
总体设计
白皮书
使用手册
管理手册
测试文档
API文档

2.5.2测试提交文档

文档说明	作者	文档位置（CVS）
《总体测试计划》
《总体测试方案》（可根据项目情况进行裁剪）
测试用例
《性能测试方案（报告）》
《测试报告》
《Readme》
《产品操作手册(后台)》
《产品操作手册(前台)》
《产品安装维护手册》
《产品错误代码说明文档》

第3章质量目标

描述本阶段测试目标和要求。质量目标应该包括产品的质量目标和测试小组的质量目标。

质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具，应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如，系统是否能够正式发行?在代码完成后，应该修复那些缺陷?在系统完成后那种类型的测试是最合适的?

3.1产品质量目标

可以是产品的质量达到什么样的目标，产品的流程联通性达到什么样的要求。

测试质量目标	确认者（如需说明）
测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确
产品规定的操作和运行稳定

3.2测试质量目标

评价测试质量的目标可以有：

测试质量目标	确认者（如需说明）
所有的测试案例已经执行过
所有的自动测试脚本已经执行通过
所有的重要等级为1/2的Bug已经解决并由测试验证
每一部分的测试已经被Test Lead确认完成
重要的功能不允许有等级为1/2/3的Bug
一般的功能或与最终使用者不直接联系的功能不允许有等级为1/2的bug,且bug等级为3的问题不得超过1/功能
轻量的功能允许有少量2/3等级的错误
发现错误等级为1/2/3的Bug的速率正在下降并接近0
在最后的三天内没有发现错误等级为1/2/3类的Bug

第4章 资源需求

4.1培训资料

培训需求	培训内容	培训人员	开始时间	完成时间
业务流程
安装配置
工具使用

4.2测试环境

4.2.1硬件测试环境

描述建立测试环境所需要的设备、用途及软件部署计划。

“机型(配置)”：此处说明所需设备的机型要求以及内存、CPU、硬盘大小的最低要求。

“用途及特殊说明”：此设备的用途，如数据库服务器，web服务器，后台开发等;如有特殊约束，如开放外部端口，封闭某端口，进行性能测试等，也写在此列;

“软件及版本”：详细说明每台设备上部署的自开发和第三方软件的名称和版本号，以便系统管理员按照此计划分配测试资源;

“预计空间”：说明第三方软件和应用程序的预计空间;

“环境约束说明”：建立此环境时的特殊约束。如需要开发外部访问端口，需要进行性能测试等。

平台1：SUN
机型（配置）	IP地址	操作系统	用途及特殊说明	软件及版本	预计空间
SUN450	10.1.1.1			oracle8.1.2	2G
平台2：IBM
机型	IP地址	操作系统	用途	第三方软件及版本	预计空间

4.2.2软件测试环境

软件需求	用途

4.3测试工具

此项目将列出测试使用的工具以及用途：

测试工具	用途
自动测试工具

第5章 测试策略

5.1 整体测试策略

本节的目的是说明计划中使用的基本的测试过程。

使用里程碑技术在测试过程中验证每个模块，测试人员在需求阶段参与测试工作，进行需求review、设计review、测试案例设计和测试开发，在系统开发完成之后，正式执行测试。产品达到软件产品质量要求和测试要求后发布，并提交相关的测试文档。

5.2开始/中断/完成标准

说明中断/开始/完成测试的标准。

开始/中断/完成测试	标准说明
开始测试标准	硬件环境可用且软件正确安装完成
中断测试标准	安装无法正确完成或程序的文档有相当多的失误或系统服务异常或发现Block Bug
完成测试标准	完成测试计划中的测试规划并达到程序和测试质量目标,并由Test Lead/R&D Manager确认

5.3测试类型

测试类型	是否采用	说明
功能测试	采用	根据系统需求文档和设计文档，检查产品是否正确实现了功能。
流程测试	采用	按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程、正反流程，检查软件在按流程操作时是否能够正确处理
边界值测试	采用	选择边界数据进行测试，确保系统功能正常，程序无异常。
容错性测试	采用	检查系统的容错能力，错误的数据输入不会对功能和系统产生非正常的影响，且程序对错误的输入有正确的提示信息
异常测试	采用	检查系统能否处理异常
启动停止测试	采用	检查每个模块能否正常启动停止、异常停止后能否正常启动
安装测试	采用	检查系统能否正确安装、配置
易用性测试	采用	检查系统是否易用友好
界面测试	采用	检查界面是否美观合理
接口测试	采用	检查系统能否与外部接口正常工作
配置测试	采用	检查配置是否合理、配置是否正常
安全性和访问控制测试	采用	应用程序级别的安全性：检查Actor只能访问其所属用户类型已被授权访问的那些功能或数据。 系统级别的安全性：检查只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序。
性能测试	采用	提取系统性能数据，检查系统是否满足在需求中所规定达到的性能。
压力测试	采用	检查系统能否承受大压力，测试产品应该能够在高强度条件下正常运行，不会出现任何错误。
兼容性测试	采用	对于 C/S 架构的系统来说，需要考虑客户端支持的系统平台。 对于 B/S 架构的系统来说需要考虑用户端浏览器的版本。
割接/升级测试	采用	进行专门的割接测试或升级测试，提供工程升级割接方案
文挡测试	采用	检查文档是否足够、描述是否合理
回归测试	采用	检查程序修改后有没有引起新的错误、是否能够正常工作以及能否满足系统的需求

5.4 测试技术

测试技术	是否采用	说明
里程碑技术	采用	里程碑的达成标准及验收方法在测试完后制订
自动测试技术	采用	核心业务流程采用自动测试技术
审评测试	采用	对软件产品功能说明文档和设计说明文档进行检查，在需求与设计阶段进行
编写测试用例	采用	在产品编码阶段编写测试用例
单元测试	不采用	由开发人员进行
集成测试	采用	检测模块集成后的系统是否达到需求对业务流程及数据流的处理是否符合标准、系统对业务流处理是否存在逻辑不严谨及错误以及是否存在不合理的标准及要求。
确认测试	采用	在产品发布前，对照feature list 进行基本需求的确认，确认产品是否正确实现了功能。
系统测试	采用	包括性能测试、压力测试和回归测试
验收测试	不采用	由工程实施人员进行

第6章 测试计划

6.1进度计划

在此章节，对各阶段的测试给出里程碑计划，包括阶段、里程碑、资源等。

6.1.1测试时间进度

测试阶段	开始时间	完成时间	测试人员	阶段完成标志
制定测试计划
需求Review
设计Review
设计测试用例
测试开发
测试环境准备
测试实施
功能测试
集成测试
性能测试
系统测试
验收测试
文档编写

6.1.2测试里程碑

里程碑	完成时间	完成标准
测试正式开始		完成可接受性测试和烟雾测试
进行CVS LOCK	进行cvs lock	完成所有里程碑测试和标准测试,测试种类包括确认测试和系统测试,且所有以发现的Bug等级为1/2/3的Bug已修复,近期内无发现新的Bug等级为1/2/3的Bug
产品Release		重复进行主路径测试和进行Bug检查测试,产品处于可交付状态并由测试经理和高级经理确认

6.2测试准备

6.2.1 测试环境准备

准备事项	开始时间	完成时间	测试人员	阶段完成标志
测试环境准备

6.2.2 安装测试

准备事项	开始时间	完成时间	测试人员	阶段完成标志
安装测试

6.2.3 烟雾测试

准备事项	开始时间	完成时间	测试人员	阶段完成标志
烟雾测试

6.3 具体测试实施任务和时间人员安排

测试功能点	开始时间	完成时间	测试人员	说明

软件测试计划 篇2

关键词：测试计划,变更,测试资源配置,问题跟踪报告

0 引言

软件测试是一个极为复杂的过程。一个规范化的软件测试过程通常须包括以下基本的测试活动：拟定软件测试计划、编制软件测试大纲、设计和生成测试用例、实施测试、生成软件问题报告。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试计划应该作为测试的起始步骤和重要环节。在越来越多公司的软件开发中，软件质量日益受到重视，测试过程也从一个相对独立的步骤越来越紧密嵌套在软件整个生命周期中。这样，如何规划整个项目周期的测试工作；如何将测试工作上升到测试管理的高度都依赖于测试计划的制定。测试计划因此成为测试工作展开的基础。

一个好的测试计划可以起到如下作用：首先避免测试的“事件驱动”，其次使测试工作和整个开发工作融合起来，最后资源和变更事先作为一个可控制的风险。

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

1 测试阶段划分

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

合理的测试阶段应遵循下面划分方法：

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

2 系统测试阶段日程安排

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

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

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

(2)由系统测试用例页数计算编写系统测试用例时间

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

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

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

(4)计算回归测试包含的时间

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

基于以上方法的优点是，可以利用已知来推算未知，适用于需求是已知且相对稳定的情况；缺点是处于研发状态的项目，需求不清晰的时候比较难计算。现用一个例子加以说明：需求文档页数为500，系统测试用例页数推算为500，则编写系统测试用例时间为500小时，执行系统测试用例时间为1000小时，回归测试需要500小时，加起来总共为2000小时，按一天8小时计算，共计250个工作日/人；假如一个月为22个工作日，则共计约11人/月，即投入4个人需要3个月左右时间工作量完成。当然，这是系统测试需要的全部时间。根据测试阶段划分原则，设计用例时间可以和开发同步进行，只需在测试阶段中安排的时间为1500小时即4人2个月工作量。值得注意的是：国内大多数公司的测试时间都是不足的，不可能按照这样的理想比例进行运作，因为测试执行的时间实际上不可能占据整个项目周期的1/2，甚至要短于其中任何一个项目阶段时间。在测试时间不足的情况下，可参考下面项目计划变更时的做法，因为计划变更也涉及到测试时间不足的情况。

3 变更的控制

测试计划改变了已往根据任务进行测试的方式，因此，为使测试计划得到贯彻和落实，测试组人员必须及时跟踪软件开发的过程，对产品提交测试做准备，测试计划的目的，本身就是强调按规划的测试战略进行测试，淘汰以任务为主的临时性。在这种情况下，测试计划中强调对变更的控制显得尤为重要。

变更来源于以下几个方面：(1)项目计划的变更；(2)需求的变更；(3)测试产品版本的变更；(4)测试资源的变更。

测试阶段的风险主要是对上述变更所造成的不确定性，有效地应对这些变更就能降低风险发生的几率。要想计划本身不成为空谈和空白无用的纸质文档，对不确定因素的预见和事先防范必须做到心中有数。

对于项目计划的变更，除了测试人员及时跟进项目以外，项目经理必须认识到测试组也是项目成员，因此必须把这些变更信息及时通知到项目组，使得整个项目得到顺延。项目计划变更一般涉及都是日程变更，令人遗憾的是，往往为了进度的原因，交付期限是既定的，项目经理不得不减少测试的时间，这样，执行测试的时间就被压缩了。由于时间不足，不能“完美”的执行所有测试，为了保证质量，第一种办法是调整测试计划中的测试策略和测试范围。调整的目的是重新检查不重要的测试部分，调换测试的次序和减少测试规模，对测试类型重新组合择优，力求在限定时间内做最重要部分的测试，可以把忽略部分留给确认测试或现场测试。其他应对办法包括减少进入测试的阻力，例如降低测试计划中系统测试准入准则；分步提交测试，例如改成迭代方式增量测试；减少回归测试的要求，例如开发人员实时修改，在测试计划中对缺陷修复响应时间和过程进行约定；简化配置管理，跳过正式发布环节；缺陷进行局部回归而不是重新全部测试等等。

项目进行过程中最不可避免的就是需求的变更。因此，制定计划时，如果项目需求处于动态变化时，在测试用例章节就要进行说明。许多测试经理在编制测试用例时往往没有把测试用例和测试数据进行区分，因而造成的问题是当需求变化时辛苦设计的数据就作废了。在这时，假使面临一个需求动态的项目，必须在计划中对需求变更造成的测试（设计）方式变化进行说明，例如采用用例和数据分离、流程和界面分离、字典项和数据元素分离的设计方式，然后等到最终需求确定后细化测试设计；另一个方面是最好制定一个变更周期的约定，尤其在执行测试阶段发现需求的变更，定义变更的最大频度和重新测试的界限，计划从一定程度上能够降低不可预期需求变化造成的投入损失。值得注意的是：需求发生变更时测试经理额外的工作是记住要在需求跟踪矩阵上做记录。

对于测试产品版本的变更，除了部分是由于需求变更造成之外，很有可能是由于修改缺陷引发的问题或配置管理不严格造成。众所周知，测试必须是基于一个稳定的“基线”进行，否则，因反复修改造成测试资源和开发资源的浪费是可观的。合理的测试计划在章节中应增加一个测试更新管理的章节，在此章节明确更新周期和暂停测试的原则。例如，小版本的产品更新不能大于每天三次，一个相对大的版本不能每周大于1次，规定紧急发布产品仅限于何种类型的修改或变更，由谁负责统一维护和同步更新测试环境。测试计划通常制定了准入和准出准则，这是不够的，要考虑测试暂停的时候，产品错误发布或者服务器数据更新就是一个例子，暂停的时候如果测试经理不进行跟踪，可能发生测试组等待测试而没人通知继续测试的情况，所以，增加更新周期和暂停测试原则是很有必要的。

最后，测试资源的变更是源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类似。没有测试经理愿意承担资源不足的测试工作，只能说公司本身是否具备以质量为主的体系或者项目经理对产品质量的重视程度如何决定了对测试资源投入的大小，最终产品质量取决因素不仅仅在于测试经理。为了排除这种风险，除了象时间不足、测试计划变更时那样缩减测试规模等等方法以外，测试经理必须在人力资源和测试环境一栏标出明确需要保证的资源，否则，必须将这个问题作为风险记录。

当然，要制定一个成功的软件项目测试计划除了做到上述之外，在实际中还应做好以下几方面：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、问题跟踪报告、测试计划的评审、结果等等。

产品基本情况调研。这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。目的重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置，粗略的估计测试大致需要的周期和最终测试报告递交的时间。技术结构可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。产品规格就是制造商和产品版本号的说明。测试范围能简单的描述如何搭建测试平台以及测试潜在的风险。项目信息说明要测试项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。

测试需求说明。这一部分要列出所有要测试的功能项，凡是没有出现在这个清单里的功能项都排除在测试的范围之外。功能的测试理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。设计的测试即对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。整体考虑这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。

测试的策略和记录。这是整个测试计划的重点所在，要描述如何公正客观地开展测试。公正性声明要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。测试案例描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的回归测试留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。需特殊考虑有的时候，针对一些外界环境的影响，要对软件进行一些特殊方面的测试。经验判断即对以往的测试中，经常出现的问题加以考虑。设想即采取一些发散性的思维，往往能帮助你找的测试的新途径。

测试资源配置。主要指项目资源计划，制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。

问题跟踪报告。在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境。问题描述尽可能是定量的，分门别类的列举。

测试计划的评审。又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。

4 结论

尽管上面尽可能的描述了测试计划如何制定才能“完美”，但是还存在的问题是对测试计划的管理和监控。一份计划投入再多的时间去做也不能保证按照这份计划进行实施。好的测试计划是成功的一半，另一半是对测试计划的执行。对小项目而言，一份更易于操作的测试计划更为实用，对中型乃至大型项目来看，测试经理的测试管理能力就显得格外重要，要确保计划不折不扣的执行下去，测试经理的人际谐调能力，项目测试的操作经验、公司的质量现状都能够对项目测试产生足够的影响。另外，计划也是“动态的”，不必要把所有的因素都可能囊括进去，也不必要针对这种变化额外制定“计划的计划”，测试计划制定不能在项目开始后束之高阁，而是紧追项目的变化，实时进行思考和贯彻，根据现实修改，然后成功实施，这才能实现测试计划的最终目标，即保证项目最终产品的质量。

参考文献

[1]倪子伟.软件开发过程[M].北京:高等教育出版社,2004.

[2]刘怀亮,相洪贵.软件质量保证与测试[M].北京:冶金工业出版社,2007.

[3]论软件测试计划的制定[EB/OL].http://www.javaeye.com/topic/356143,2009年3月.

金和软件育林计划覆盖23个城市 篇3

咕咚网获盛大投资和科技创新基金支持

本报讯 成都乐动信息技术有限公司近日宣布，其开发的基于物联网技术的运动-饮食-睡眠多维监控系统，以及分享运动乐趣的网络社交平台——咕咚网（www.codoon.com)，已经获得盛大集团的大额注资，并获得了国家中小企业科技创新基金的60万元无偿支持。

惠普与慧聪力推中小企业“惠商联盟”

本报讯 近日，惠普联手慧聪，推出面向中小企业的交流平台——惠商联盟。旨在为中小企业提供实用的成功经验分享、打印科技服务。

淘宝联盟年内将实现日交易额过亿元

本报讯 近日，电子商务专业营销平台淘宝联盟宣布，通过其产生的日交易额已经突破3600万元，合作伙伴分成达350万元。预计2011年，通过淘宝联盟产生的日交易额将达到1亿元，而其带给合作伙伴的日均分成也将突破800万元。

华硕发布无线网络产品2011年市场策略

本报讯 近日，华硕无线网络产品正式发布2011年市场策略——“科技，易起来”。华硕电脑网络产品事业部产品总监高勇表示，易用性是华硕创新科技的直观体现，也是华硕无线网络产品追求的目标。华硕无线网络产品包含了6大创新技术，这些技术从安装、应用、管理、节能、定位等多个方面，将无线网络产品的技术标准推到了全新的高度。

人人网客户端亮相Meego平板电脑

本报讯 4月12日，人人网开发的首款用于Meego平板电脑操作系统的客户端亮相英特尔信息技术峰会(IDF)，这是英特尔与SNS网站在全球范围内的首次联袂。据悉，这个客户端集浏览、发布、评论、转发、娱乐等功能于一体，将为用户提供便捷、精彩的移动互联网体验。

AOC联合《里约大冒险》推广“立影3D”显示器

本报讯近日，AOC举行了以“立影袭来，奇迹之约”为主题的“立影3D”e2352Pz显示器新品发布暨动画电影《里约大冒险》合作启动仪式。据了解，AOC“立影3D”e2352Pz具有不闪烁、高亮度、无重影、眼镜佩戴舒适等特点。

搜狗浏览器3.0预览版推出网页更新服务功能

本报讯日前，搜狗浏览器发布了3.0预览版，其中推出了网页更新提醒服务，可智能检测网页中更新的内容并进行标黄显示，帮助用户迅速定位。新版搜狗还内置了用户在冲浪上网时最常使用的多款小工具。

2011英特尔极客炫世界大学生项目全面启动

本报讯 4月14日， 2011英特尔极客炫世界项目正式启动。这是针对大学生人群的一个长期活动，内容涵盖艺术与科技的碰撞、个人职业发展规划以及英特尔的领先科技给生活带来的改变等方面。

京东商城启动第三届手机节

本报讯 日前，京东商城推出第三届手机节，回馈活动整体让利1000万元。据了解，京东商城将与联通同步推出苹果iPhone4“购手机入网送话费”合约计划，新的iPhone4合约价格直降千元。 同时推出99元名牌手机不定时秒杀，大量299元动感手机、诺基亚E71等机型以超低价限量抢购。

联想扬天春促启动

热工测试计划 篇4

为执行国家质检总局关于做好2011年高耗能特种设备节能工作的实施意见中，关于锅炉设计文件节能审查和锅炉定型产品能效测试工作的要求，对我公司的6t/h，10 t/h链条炉进行能效测试。1.测试时间：

经与省特检院沟通，基本定于7月20-25日左右进行正式测试。争取在7月底前将6t/h，10 t/h链条炉测试完毕。6t/h链条炉用户单位每周二、五停电，故大致定于7月21日（周四）对6t/h链条炉进行测试。最终测试时间和用户确认和特检院确认后确定。2.测试前期调试

为顺利进行测试，根据现场情况，提前一天（7月20日）我公司先行进行调试准备，锅炉测试主要项目有：

1.）给水压力、给水流量、给水温度（给水旁路和给水流量计，给水旁路安装由用户单位协助安装。）

2.）蒸汽压力、蒸汽湿度（需炉水、蒸汽冷凝器，6t/h链条炉只有炉水冷凝器，现场要在主蒸汽管道上开孔安装。因涉及受压部件开孔，蒸汽取样由我公司负责安装，需提供蒸汽取样装置，取样冷却装置以及配套的法兰，阀门等。需要生产部门的配合）

3.）排烟温度、烟气成分。烟温测量由现场解决。调试需要设备需要外借。3.各部门职责：

1.）技术部门：召集测试会议，确定本次测试参加人员；提供测试需要图纸，测试注意事项；给水旁路和蒸汽取样装置的安装示意图。参与锅炉调试，配合特检院的测试工作。2.）销售部门：联系用户，测试需要用煤数量、用汽排放问题，确定测试时间。安排测试用车及和特检院必要的公关。调试需要设备的外借。

3.）用户服务：现场要在主蒸汽管道上开孔安装。因涉及受压部件开孔，蒸汽取样由我公司负责安装，需提供蒸汽取样装置，取样冷却装置以及配套的法兰，阀门等（型号，规格，数量由技术部门提出）。需持证电焊工协助现场焊接。

1—主蒸汽管

2—蒸汽取样管

附图2

注：蒸汽取样管用4分水管引至距地面90厘米处，端口攻好螺纹，以便与蒸汽冷凝器上的4分阀门联接。

注: 实线部分为锅炉厂在试验前现场准备完毕。虚线部分为特检院准备，试验时安装。

附图 1

灯具测试计划 篇5

测试输出功率和额定输出是否一致：：

Table 3 No.1 2 3 4 5 6 7 8

Input test data Voltage Frequency 50 60 50 60 50 60 50 60 Ampere(A)Watts(W)Note

P

Max.normal load Max.normal load Max.normal load Max.normal load Max.normal load Max.normal load

Under +10% of Rated Voltage and-9% of Rated Voltage 输入电流按+10%评估

Table 5.2 TABLE: supply connection, strain relief test Cross-sectional Pull force(N)Duration(s)area: 60 1 25 Times

P Required move Measured distance 2mm distance

Table 7.2.3 Location

TABLE: ground continue test Resistant measured(Ω)Comments

N

Output ground to input ground Note: Test with following current: Pass: < 0.5 Ohm

10A, 1 minute

Table 8.1 Location For model:

TABLE: Electronic shock test Voltage(V)Current(mA)Freq.(kHz)Limit(mA)

N Comments

Y-capacitor secondary pin to earth Note(s): Under the highest Rated Voltage.

CY= pF

8.2.7 Condition

TABLE: discharge test

N

τ
calculated(s)

τ
measured(s)

t u→ 0V Comments(s)

For model: System on/off Note(s): Under the highest Rated Voltage.-V0= V,

Table 9.3

TABLE: Moisture resistance, humidity treatment Test condition:

P

Ambient(℃)Humidity(﹪)Duration(h)25 95% 48h

The sample is kept in a test room having a normal atmosphere for 24h before testing.

Table 10.2.2

TABLE: electric strength measurements

P

Test voltage applied between:

Test voltage(Vac)

Breakdown(Yes/No)No No No No No

L/N and secondary circuits L/N and user accessible area(with metal foil)T1 primary and secondary T1 secondary and core 1 layer insulation tape of T1 Note(s):--

3710Vac 3710Vac 3710Vac 3710Vac 3710Vac

Table 10.3 TABLE: touch current measurement

P

Condition

L→ terminal A(mA)

N → terminal(mA)

Limit(mA)

Comments

System on System on System on Note(s):

0.5 0.5 0.5

Output “+” Output “-“ Enclosure with metal foil

Input voltage: Under the highest Rated Voltage.

Table: working voltage measurement Location RMS voltage(V)Peak voltage(V)Comments

P

Transformer T: T pin T pin T pin T pin T pin T pin T pin Tpin Photo-coupler:

Table 11.1

TABLE: clearance and creepage distance measurements R.M.S(V)

P

clearance cl,creepage distance Require Measur Require Measur dcr at/of: Measurement points d cl ed cl d dcr ed dcr(mm)(mm)(mm)(mm)

Peak(V)

Primary circuit to enclosure Transformer secondary Transformer core to secondary Primary circuit to secondary circuit Different polarity before fuse Two terminals between fuse primary to

Table 12.4 No.1 2 3 4 5 6 7 8 9 10 11

Heating under normal operating conditions 1.06 times rated voltage measured t(C)
。

P Limit t(C)
。

Test points

Plastic enclosure Metal enclosure Ambient Pass: Depends on allowed ambient temperature(min.25°C)

75 60

Table 12.5

TABLE: fault condition tests(shorted or opened)

P

No.1 2 3 4 5

Compon ents

Fault status

Test voltage

Duratio n

Results

Note: S-C=short circuit Under +10% of Rated Voltage.Pass: Depends

on allowed ambient temperature(min.25°C)

Table 13.1 Part PCB Bobbin of Transformer

TABLE: ball pressure test of thermoplastics Test temperature(℃)Impression diameter(mm)

P Required impression diameter(mm)≤2.0 ≤2.0

Plastic lamp holder

≤2.0

13.3.2 Part at:/ Enclosure

TABLE: glow wire test Test temperature(° C)650 650 Result No any flame or glowing No any flame or glowing

P

Bobbin of transformer

测试工作计划 篇6

将确定被当作测试对象的各项需求（例如用例、功能性需求和非功能性需求）的跟踪管理矩阵明确列出，并列出将要测试的对象以及测试优先级、优先级分为：H—必须测试；M—应该测试，只有在测试完所有H项后才进行该测试；L—可能会测试，但只有在测试完所有H和M项后才进行测试

详情请参见《测试管理工作表》测试用例状态跟踪页、

3测试资源

3、1人力资源

下表列出在此项目的人员配备方面所做的各种假定，包括在各个阶段需要介入测试的各种角色以及相关的职责和权限等

3、2系统资源

软件项目计划与监控方法研究 篇7

根据国际上通行的划分方法,项目管理生命周期可以划分为启动、计划、执行及收尾四个大的阶段,其中项目的计划与执行则是关系到项目成败与否的最重要的两个关键过程。通过项目策划所产生的项目计划是有效协调项目工作,推动项目工作顺利进行的最重要的工具。只有通过有效的项目策划,才能对制约项目的因素,特别是几处关键因素,如成本、进度及技术性能等做出有效的安排,并为随后的监督与控制,提供切实可行的基础和标准;而进行有效地项目执行,即项目的监督与控制则是确保项目计划得到有效实施的重要手段。

众所周知,自顶向下估计方法是软件项目策划中一种非常适用和重要的策划方法,特别是在项目初期,更是如此。本文针对软件项目所固有的特点,重点研究和介绍了计划与执行这两个关键过程在软件项目自顶向下策划方法中的应用,根据自顶向下方法的特点进行计划,并据此进行项目的执行和监控。根据现在国内外软件行业项目管理的现状和水平,我们应本着循序渐进的原则,逐步改进和完善我们的项目计划和监控方法。

2 自顶向下方法估计及监控

所谓的自顶向下估计方法,就是先根据需求进行规模估计,根据规模估计结果来估计项目的总工作量,再根据工作量情况考虑到各种依赖关系及关键路径等,并对工作量进行分解后得到项目的进度,见图1。自顶向下方法是相对于自底向上方法而言的,在自底向上估计方法中,是通过直接估计每一部分的工作量,来获得项目的总工作量。下面分别对规模、工作量及进度的估计、监控方法及其逻辑关系进行介绍。

2.1 进行规模估计与监控

2.1.1 进行规模估计

一般情况下,规模估计的方法有Delphi法、类比法、功能点估计法及PERT估计法等。下面以类比法和PERT法为例,对其使用情况进行说明。

类比法适合评估一些与历史项目在应用领域、环境和复杂度方面相似的项目,通过新项目与历史项目的比较得到规模估计。而PERT法则对各个项目的规模按三种不同情况估计:一是最可能估计(最接近值),二是最低估计(最小值),三是最高估计(最大值)。用这三种情况估计经计算得到一个产品期望规模和标准偏差的Pert统计估计。通过Pert估计可得到代码行的期望值E和标准偏差SD.

一般情况,在有历史数据的情况下使用类比法较多,在没有历史数据的情况下使用PERT法较多。在实际工作中,我们认为在有历史数据的情况下可尝试将类比法与PERT法两种估计方法结合使用,其效果则更佳。具体使用如下:

步骤1.

参与估计的人员分别独立地依据个人的经验(有历史数据的参考历史数据),按照产品功能结构图估计每一个功能模块的代码行数,分别列出最大值、最接近值及最小值,并计算出各项的期望值。期望值的计算公式为:(最大值+4*最接近值+最小值)/6。

步骤2.

项目经理汇总每个成员估计的期望值,对数据进行对比分析。如果个人估计的各项总值的差额的百分比小于30%,则取个人各项的平均值;如果差额的百分比超过30%,则要重新进行估计,转向步骤1。

步骤3.

对于选择出的数值,策划组的成员要对此进行分析和评审,确定出最终的产品规模估计值。

2.1.2 进行规模监控

因为项目工作量和进度是在规模估计的基础上进行的,因此规模的大小直接决定到工作量的大小并影响到项目的进度,因此应对规模进行监控。规模监控的主要步骤可系统地设定如下:

· 在项目策划阶段,采集规模估计值。

· 从计划开始执行到详细设计评审前,每个大的阶段结束,都应对规模进行重新估计,比较当前估计值与最新计划中的估计值,并记录偏差。

· 根据项目计划中定义的偏差域值,识别是否有重大偏差,偏差的设定根据组织自身的情况可有很多种方法,如可设定为:若规模的偏差值/规模总量*100%=10%,则为高等级偏差,必须对计划进行变更;若偏差率在5%—10%之间,则由项目负责人组织制定相应的纠正措施,改善项目的整体状态等。

· 在编码阶段开始后,开发人员每周提交已完成任务的代码,项目负责人或其指派人员测量已提交代码的规模,并用工具进行汇总、统计(如EXCEL),根据工具自动生成的规模总计进行分析,并预计是否会出现重大偏差。根据本周完成的任务数(项目编码阶段的阶段计划要求细化到任务),与项目阶段计划相比较,参考本周完成的代码行数,看阶段计划能否完成,阶段计划有无偏差出现。

· 根据记录及统计情况,分析偏差产生的原因,以及可能对项目产生的影响,并根据分析情况给出建议措施。例如:

◆ 当偏差未达到域值(即重大偏差)时,分析偏差产生的原因及影响,并根据分析情况确定是否需采取纠正措施(如对工作量进行重新估计等)。

◆ 当偏差达到域值时,应进行重新估计。

2.2 进行工作量估计与监控

2.2.1 进行工作量估计

项目工作量与规模的对应关系为:技术开发工作量=新代码规模*复杂度/平均生产率。其中,根据上述描述,新代码规模根据本文“2.1”中描述的规模估计方法进行估计得出,平均生产率根据对组织项目历史数据的统计分析确定;复杂度可定义范围为0.7-1.5,可以有5个值:非常低、低、正常、高、非常高;具体影响因素的设定需根据各组织的实际情况确定。

参与估计的成员根据公司产品规模的估计数据及公司的产品工作量与产品规模关系的对应关系,对产品开发的总体工作量进行估计,并依据历史数据统计分析得出的比例关系分解出各项开发过程的工作和项目管理、软件质量保证及软件配置管理的工作量的估计值。

2.2.2 进行工作量监控

对于软件企业来说,工作量是构成项目成本的一个重要的因素,也是进行进度分解和估计的基础,因此对工作量的监控是监督与控制的一个重点。工作量监控的主要步骤可系统地设定如下:

· 在项目策划阶段,采集工作量估计值。

· 每周采集当前阶段每个任务本周的工作量,并累加计算出每个任务“实际”工作量,再累加计算出该阶段“实际”工作量。对于工作量的每周监控主要应达到三个目的:一是可以判断总的阶段工作量有无可能出现重大偏差;二是通过每周工作量的计算,可以辅助观察阶段进度会否出现偏差;三是通过工作量的监控,对督促员工按时完成任务,提高工作效率,将起到很好的促进作用。

· 每阶段计算“偏差(当前计划)”,并根据项目开发计划中定义的标准判断“是否重大偏差”,在项目结束时计算“总计”和“偏差(初始计划)”,偏差的设定举例如:工作量的偏差值/阶段工作总量*100%=50%为高等级偏差,必须对计划进行变更;如果偏差率在40%—50%之间,由项目负责人采取相应的纠正措施来改善项目的偏离。在实际执行过程中,也可根据项目实际情况来设定项目的偏差标准,如可用工作量的偏差值/项目工作总量*100%来设定重大偏差等。

· 对项目工作量进行分析,并根据分析的结果分析偏差产生的原因,以及可能对项目产生的影响,给出建议措施。例如:

◇当偏差未达到域值(即重大偏差)时,分析偏差产生的原因及影响,并确定是否需采取纠正措施。如:分析是因估计不准而出现偏差,还是项目人员积极性不高,效率低导致,还是出现了什么问题等。

◇当偏差达到域值时,应进行重新估计。

2.3 进行进度估计与监控

2.3.1 进行进度估计

项目策划小组根据项目总工作量及工作量在各阶段的分布情况,并依据项目生命周期、活动WBS、所识别的关键路径及依赖关系,对项目的各开发阶段时间进度表进行估计,具体步骤如下:

步骤1.

根据合同或市场期望的时间确定项目的总体时间要求,即项目的完成日期。

步骤2.

按照所选择的软件生命周期模型及产品工作量的估计值,确定项目的各项任务和时间。

步骤3.

根据产品的功能WBS,分析各阶段任务的关键依赖关系,识别关键路径。确定哪些模块可以并行独立开发,哪些模块必须串行开发,定义出各功能模块的开发顺序,列出模块的开发顺序表,尤其要标明模块之间的依赖关系。

步骤4.

根据合同或市场期望的时间要求,产品工作量的估计值、各功能模块之间的依赖关系做出项目时间进度的估计,并在每阶段开始时,制定详细的阶段计划。在进行该步骤时,必须抛去一些不可用的工作时间,如节假日、员工请假、公司各项活动及其他所有在项目进行过程中必须抛去的非工作时间或非项目工作时间。

2.3.2 进行进度监控

成本、进度及功能是制约项目成功与否最重要的三大因素,因此对进度的监控也是项目计划及监控工作的一个重中之重,项目进度监控的主要步骤可系统地设定如下:

· 采集初始计划和当前计划中的“计划开始/结束日期”,在每阶段/任务开始时,采集该阶段/任务“实际开始日期”。

· 每周采集项目任务的实际进度情况。

· 对项目进度进行分析,识别偏差。例如:我们可设定,拖延的工期/总工期*100%=15%为高等级的偏差,组织要求必须对计划进行更改;如果比率在5%—15%之间,由项目负责人组织制定相应的纠正措施,改善项目的整体状态。另外,对于进度的偏差计算,还可以有其他的设定方式,如以拖延的工期/阶段工期*100%来计算等。

· 对进度的监控可用PROJECT,采用甘特图的形式来进行。

· 分析偏差产生的原因,以及可能对项目产生的影响,给出建议措施。例如:

◇ 在每周的测量中,对照细化的开发计划,如偏差较小,分析偏差产生的影响,可由项目负责人对阶段计划做细微调整,以消除偏差;

◇当偏差有可能导致重大偏差时,应采取相应的纠正措施,避免重大偏差的发生。

◇当偏差达到域值(即重大偏差)时,应分析原因,进行重新估计。

3 结语

通过上述对规模、工作量及进度的计划与执行,既可以根据自顶向下策划方法的特点对软件项目进行有效地策划,并对整个策划过程的结果根据其逻辑关系进行有效的控制,又可以通过对工作量的计划和控制实现对成本的计划与控制,而通过对规模的计划与控制实现对质量和范围的计划与控制。

总之,项目的计划与执行是一项关系到项目成败的关键活动,因此必须使用合理、正确的计划与执行方法来进行。理论和实践都证明自顶向下的估计方法是一种行之有效、可操作性极强的项目计划与执行方法,这种方法对于自底向上估计等其他策划方法也具有很大的借鉴意义。随着经验和数据的积累,计划与执行体系必将会越来越完善,我们相信项目的成功率也会越来越高。对项目计划的合理实施和监控,必将促进项目策划工作的进一步完善,而项目策划的完善又必将会为监控工作提供合理的监控基础,进而促进监控工作的顺利进行。通过项目经验及历史数据的不断积累和丰富,自顶向下计划与执行方法的作用将不断显现,其所能产生的经济效益和社会效益也将越来越大。

摘要：结合一些实际项目的数据,重点研究了自顶向下估计方法中软件项目的规模、工作量及进度等关系到项目成败的关键因素的计划与监控。提出了用PERT法和类比法相结合来进行规模估计,根据规模估计的结果来估计工作量,并根据工作量分布来获得进度的一套切实可行的项目策划和执行方法。在研究过程中,既考虑了单个因素的计划与执行,又考虑了各要素间的内在联系,从过程管理的角度进行整体研究,从而形成了一个完整的计划与监控体系,对于同行具有借鉴意义。

关键词：自顶向下,规模,工作量,进度,计划,执行

参考文献

[1]MARCEL KORTE.Confidence in Software Cost Estimation ResultsBased on MMRE and PRED[C].Proceedings of the 4th Interna-tional Workshop on Predictor Models in Software Engineering,2008:63-70.

[2]ROGER S PRESSMAN.Software Engineering,A Practitioner’s Ap-proach[M].Fifth Edition.McGraw-Hill Companies,Inc.

[3]MASOOD A BADRI,AMR MORTAGY.Effective Analysis and Plan-ning of R&D Stages:A Simulation Approach[J].International Jour-nal of Project Management,1997,15(6):351-358.

[4]R S CHANDA,P K BHATTACHARJEE.A Reliability Approach toTransmission Expansion Planning Using Fuzzy Fault-tree Model[J].Electric Power Systems Research,1998,45:101-108.

[5]M ABDOMEROVIC,G BLAKEMORE.Project Process Interactions[J].International Journal of Project Management,2002,20:315-323.

[6]HARVEY MAYLOR.Assessing the Relationship between PracticeChanges and Process Improvement in New Product Development[J].Omega,2001,29:85-96.

[7]K VINAY KUMAR.Software Development Cost Estimation UsingWavelet Neural Networks[J].Journal of Systems and Software,2008,73(1):93.

[8]美国项目管理学会(PMI).项目管理知识体系指南(2000中文版)[M].北京:北京现代卓越管理技术交流中心.

[9]RUCHI SHUKLA.Estimating Software Maintenance Effort:A NeuralNetwork Approach[C].Proceedings of the 1st Conference on IndiaSoftware Engineering Conference Table of Contents,2008:107-112.

软件测试计划 篇8

关键词：项目管理；资源平衡；网络计划

工程项目管理是以工程项目为对象，在有限的资源约束条件下，为了最优地实现工程项目目标和达到规定的工程质量标准，根据工程项目建设的内在规律性，运用现代管理理论与方法，对工程项目从策划决策到竣工交付使用全过程进行计划、组织、协调和控制等系统化管理的过程。在工程项目的进度管理中，限于资源的约束，网络计划的作业之间除了存在工作逻辑的联系，逻辑上无关系的作业也有可能因为需要同种资源而存在联系。因此，在安排各项作业逻辑关系时就要考虑资源的限制和资源的供应过程对网络计划的影响。对网络计划进行资源优化，不仅可以方便资源调配，而且能够降低工程成本。本文通过加权平均将多资源转化为单一资源综合指标，通过项目管理软件对总承包工程施工专项计划进行“工期固定，资源均衡”的优化，获得了较好的应用效果。

1.网络计划技术的优点

在工程项目管理的过程中，通过网络计划图和计算可以找出网络计划的关键线路和次关键线路，这种线路上的工作，花费时间长，消耗资源多，所以我们可以把整个工程项目有效地组织起来 ，明确地反映出整个项目的结构、相互关系，使组织者能够统筹兼、抓住关键， 确保计划实现，避免造成浪费。与关键线路相呼应，利用网络计划可计算出除关键工作外其他工作的机动时间。对于每项工作的机动时间做到心中有数，有利于工作中利用这些机动时间，优化资源强度，支持关键工作，调整工作进程，降低成本，提高管理水平。使用网络计划技术对施工现场的质量管理有很大帮助。虽然一般认为网络计划是进度控制的手段 ，但从影响施工现场质量因素的分析中可以看出 ，采用网络计划技术 ，将有助于施工现场的质量管理。

2.网络计划技术应用现状分析

据有关资料分析，目前我国网络计划技术的理论研究与应用水平，尚处在中间状态，虽然我们在理论水平与应用方面同发达国家相比相差无几，但在应用管理上，特别是计划执行中的监督、控制及跟踪调整方面，较少落在实处，基本停留在编制上，主要影响为工程设计多变，材料供应跟不上，应用者素质不高。目前我国在网络计划技术的理论研究方面同国外发达国家相比相差无几，但在应用管理上比较落后，基本上停留在计划的编制与网络图绘制上。许多企业运用网络计划，或因招投标文件所要求，或为投标施工组织增加“技术含量”。所以如此绘制出的网络图不是错误连篇，就是华而不实，根本谈不上如何运用这一科学管理方法进行项目管理。绝大部分施工企业网络计划技术的应用只停留在编制计划或画出几张网络图上，对计划执行中的监督与控制及计划调整缺少有效的管理方法。网络计划在真正的应用过程中，应该对于实际进度滞后的项目通过改变某些后续工作的逻辑关系或缩短某些后续工作的持续时间 ，并制定相应保证措施来调整偏差。在施工网络计划的编制中，只是确定各工作单元之间的逻辑关系，而没有根据施工方法确定工作单元中各项工作之间的所有关系。编制深度不够，更谈不上网络计划的优化与控制。

3.网络计划资源优化方法分析

3.1资源优化

在通常情况下，网络计划的资源优化分为两种。“资源有限，工期最短”的优化是在资源供应有限制的条件下，寻求整个计划工期最短的方案。“工期固定，资源均衡”的优化是通过调整计划安排，在工期保持不变的条件下，使资源需用量尽可能均衡的过程。这里所讲的资源优化，其前提条件是在优化过程中，不改变网络计划中各项工作之间的逻辑关系；在优化过程中，不改变网络计划中各项工作的持续时间；网络计划中各项工作的资源强度为常数，而且是合理的；除规定可中断的工作外，一般不允许中断工作，应保持其连续性。衡量资源不均衡程度的指标有三种：资源需要量不均衡系数、资源需要量方差和极差。三种指标均是值越小，资源的均衡性越好。在实际工程中，很难使上述指标都达到最小，一般选用方差作为衡量指标，即资源需要量与单位时间平均需要量之差的平方和的平均值。

3.2多资源优化

资源作为工程项目实施的基本要素，它通常包括：人力，包括各专业、各种级别的劳动力以及不同层次和职能的管理人员；原材料和设备，它构成工程的实体，例如常见的砂石、水泥、砖、钢筋、木材、设备等；施工所需设备，如塔吊、混凝土拌合设备、运输设备和施工工具。此外，资源还可能包括资金、计算机软件、信息系统、专利技术和方法等。工程中各种工作所需资源的种类及数量不同决定了每种资源的需求曲线不尽相同。调整网络计划的非关键作业会对各种资源的均衡效果产生不同的影响，有可能会导致在改善有些资源平衡效果的同时又破坏了另一些资源的平衡状态，加大其不平衡程度。简单的重复使用单一资源均衡优化的方法不能解决多资源优化的问题，甚至出现矛盾。如果引入权重系数，，且所有种资源的权重和为，即。根据工程实际，按照各种资源对工程的影响程度进行加权平均，计算出综合资源指标，可以将多资源平衡问题转化为单一资源平衡优化。这样，对网络计划进行“工期固定，资源均衡”就是找出满足工期规定条件的网络计划关键路径和关键作业并计算总工期，计算各个非关键作业的总时差和自由时差。保持关键作业不动，调整非关键作业的开始时间，直到综合资源指标分布函数方差最小。

4.项目管理软件资源平衡实践分析

4.1适应性调整

Primavera早先版本的软件Primavera Project Planner，简称P3，对项目资源使用的规划只能由软件自动按照相应任务的计划时间将资源预算量分摊到每个时间周期中去。单纯使用软件功能规划资源的方式并不灵活，资源的分布柱状图非常平齐，这种情况在工程中是不现实的。目前的P6软件允许用户在软件自动分摊周期数量的基础上手工编制或调整资源在每个时间周期内的使用数量，以便根据实际情况更合理的规划项目资源使用。

4.2 P6软件资源平衡

用手工计算的方法对网络计划进行资源优化，计算调整工作量十分巨大，而且准确性也得不到保证，以往在实际工作中很难起到作用。在工程上应用项目管理软件可以替代繁琐的手工计算，为网络计划的资源优化提供便利，能够实现资源的动态分析与优化，使网络计划的及时更新成为可能。Primavera项目管理软件，简称P6，是用于项目组织协调的综合计划与控制软件，在国内外工程项目管理中都获得了广泛的应用。在EPC总承包工程中应用P6软件编制施工专项计划，按照多资源加权平均转化为单一资源综合指标的方法。专项计划的资源需求集中分布在工作周期的前半段，部分时段超出了资源限值，而且在第3天和第4天出现了最高峰，工作周期的后半段资源需求较少，整体分布不均。根据工程的实际情况和施工组织进行评估，近似认为该专项计划每日的资源综合指标限值为90，需要用P6软件的资源平衡功能对施工专项计划进行资源平衡。在工程实际中，资源的限值并不是一个绝对严格的数值。现场设计变更、设备材料的供货进展、工作难度的不同、施工工作面的布置以及劳动效率的变化都会影响权重的分配和权值估算的准确性，进而影响资源综合指标的数值。

5.结束语

资源优化的准确性受原始数据收集积累以及资源权重系数的影响。因此，对工程项目管理的基础数据要多收集、整理，通过不断分析和总结才能逐步提高资源均衡优化的质量及可靠性，使之更好地为工程管理服务。网络计划的资源均衡优化只是相对均衡，不可能绝对优化。在工程项目管理过程中还必须根据实际情况采用其它辅助措施，才能真正满足资源供需的矛盾。

参考文献：

[1]刘炳南.工程项目管理[M]. 西安： 西安交通大学出版社， 2012.