软件测试管理方法

软件测试管理方法（共12篇）

软件测试管理方法 篇1

随着社会的进步以及经济的发展, 软件的规模不断加大, 其复杂度也在不断提高, 导致软件的开发与过程管理困难重重, 软件项目出现成本超支、进度拖延以及质量较低等情况。就目前而言, 中小软件企业在软件过程管理中, 其存在一系列的问题, 如难以控制任务完成进度, 难以控制需求, 软件质量难以控制, 软件版本混乱等, 导致软件质量和交付受到严重影响, 降低了软件的满意度。为了有效改变这种现状, 中小软件企业对软件过程改进、管理以及规范等方面采取了辅助手段, 如CMM/CMMI认证、质量管理体系的建立等, 从而促进中小软件企业的可持续发展。

1 中小软件企业软件过程管理概述

1.1 中小软件企业特点分析

在我国软件产业中, 中小软件企业占据着较大的比例, 其主要特点是熟悉行业需求, 能够对优势业务领域加以有效把握, 执行力高, 管理快捷清晰, 组织结构简洁, 响应速度快等。但是中小软件企业也存在一定的劣势, 其具有较高的维护成本, 总收入中软件销售收入占据的比例低, 经验到制度的转化程度不高, 依赖性强, 制度约束力不高, 人员流动性高以及人力资源不足等。

1.2 软件过程概念

软件过程主要指的是软件开发人员在对软件以及相关的产品进行开发与维护时, 其形成的方法、实践、行为以及变化过程。一般在对软件过程进行管理时, 必须要确保软件产品的质量, 加强其开发与维护过程的质量, 将方法, 工具以及人员进行有机结合, 从而确保软件产品的质量, 提高管理的水平。

2 中下软件企业软件过程管理的改进方法

2.1 加强质量保证与配置管理

一个软件项目的配置项包括该项目的所有相关资料, 如安装程序、工具、代码以及文档等, 配置管理良好是保证软件一致性的重要前提。因此对配置管理进行合理计划, 并对配置管理软件进行恰当选择, 统一管理软件版本, 制定基线配置项变更控制流程, 能够确保软件开发与管理过程的合理性, 提高软件过程管理以及软件产品的质量。在改进软件过程时, 中小软件企业可以从以下几个方面进行考虑:一是在对软件进行测试时, 侧重于控制和检查软件产品的质量, 并且在保证质量的同时, 严格检查和控制软件过程。二是质量保证由专人进行, 从项目计划以及阶段成果等方面进行检测, 对质量问题进行跟踪和记录, 从而有效提高软件产品的质量, 确保产品质量的维护性以及延续性。

2.2 选择重点, 优先突破

在对软件过程进行改进时, 必须要对其重点领域进行选择, 循序渐进。由于软件过程改进是对现有的软件开发与管理过程进行改善, 这对于企业管理人员以及开发人员而言, 具有较大的难度。因此在软件过程改进过程中, 企业可以有针对性地选择改进重点, 逐渐突破, 从而确保软件改进过程的合理性以及科学性。此外, 从软件开发过程而言, 软件企业不同, 使得软件项目开发的过程也不尽相同, 在软件开发过程中, 其编码、设计以及需求等阶段受企业开发人员的综合能力、知识经验以及企业自身的技术水平的影响, 因此必须要对软件过程的相关部分进行重点选择, 有效突破。

2.3 加强自评估

中小软件企业为了保证软件过程的完整性以及规范性, 往往会对软件过程进行盲目改进, 无法对自身软件过程的阶段和水平进行全面清晰的分析, 导致实施的效果低下。因此, 中小软件企业在对自身的软件过程进行改进时, 必须要加强自评估, 有效采用某磐软件度量方法, 利用定量和定性相结合的方式, 提高软件过程状态的评价。此外, 中小软件企业可以在组织内部对岗位的人员进行不同选择, 确保全体人员能够参与到软件的评估过程中, 从而保证软件过程的合理性和准确性。

2.4 重视个体软件过程改进

开发人员作为软件企业中的主体, 其工作计划的恰当性、缺陷率、时间利用率和编码质量的高低等都会影响组织软件过程和软件质量。因此为了提高开发人员的工作效率, 确保软件过程的管理质量, 必须要重视个体软件过程的改进工作。一般个体软件过程具有完整的规程、表格以及方法, 其能够对软件开发人员的工作方式进行改进、管理和控制, 对开发人员计划、管理和度量自身的工作具有指导作用。个体软件过程改进能够对时间利用的情况进行记录, 从而有效掌握时间利用率以及工作的效率;同时能够利用管理缺陷, 有效控制软件缺陷, 并提高相关人员的工作能力。

2.5 合理利用辅助工具

一般而言, 软件过程管理及其改进在很大程度上属于管理的过程, 需要遵守一定的规则, 充分合理利辅助工具, 能够有效提高软件过程管理的水平和质量。就目前而言, 软件企业常用的软件类别包括缺陷管理工具、软件测试工具、配置管理工具以及项目管理工具等, 这些工具具有完善和强大的功能。因此企业能够从自身的实际情况出发, 对这些软件工具进行合理选择与利用, 从而提高软件过程管理的水平, 增强企业的综合竞争实力, 实现企业的可持续发展。

3 结束语

一般来说, 软件过程改进是一个循序渐进的过程, 中小软件企业必须要不断积累和丰富自身的经验, 对软件过程管理进行持续改进。同时, 中小软件企业在对软件过程进行管理和改进时, 必须要加强质量保证与配置管理, 选择重点, 优先突破, 加强自评估, 重视个体软件过程改进, 合理利用辅助工具, 从而提高软件过程管理的水平, 实现自身的可持续发展。

参考文献

[1]楚书来, 于文新.小规模软件企业软件过程管理与改进策略研究[J].黑龙江科技信息, 2012, 02:199-200.

[2]田丽从, 李铁牛, 彭宏.中小型企业软件过程改进方法研究[J].计算机应用与软件, 2011, 04:208-211.

[3]李楠.我国中小软件企业实施CMM改进软件过程的研究[J].中国城市经济, 2011, 26:129-130.

[4]马小龙.一种中小型软件企业软件过程改进框架研究[J].电脑与电信, 2010, 10:38-39.

软件测试管理方法 篇2

对企业需求的描述可以从2个方面来进行描述，一个方面是对客户现行系统的描述，一个方面是对系统未来的设想。总的而言，无论是从那个方面来描述，构成企业信息系统主要包括5个基本要素：企业的组织结构、流程、数据、商务规则与功能（性能）。其中从用户的角度主要关注流程，是以流程为核心的，通过流程将其他几个要素贯穿起来，需求分析人员也应该从这个角度来和用户沟通；从开发者的角度主要关注企业的数据、商务规则与功能，以便于系统的实现；从实施者的角度主要关注企业的组织结构与功能，以便于系统的发布与实施。

1）企业的组织模型

即企业的组织结构关系，包括部门设置、岗位设置、岗位职责等。树型组织结构图是描述企业的组织模型的一种常用方法，它可用来搞清各部门之间的领导关系,每个部门内部的人员配备情况, 职责分工等情况,它是划分系统范围,进行系统网络规划的基础。在组织结构图中应将用户的组织结构逐层详细描述，每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围具有很好的帮助。取得用户的组织结构图，是需求获取步骤中的基础工作之一。

用户环境中的企业岗位或角色，和组织机构一样，也是分析人员理解企业业务的基础，也是分析人员提取对象的基础。

对用户角色的识别常常遗漏的是计算机系统的系统管理人员，角色识别不全，对以后的功能识别会造成盲区。

2）企业的流程模型

即企业的业务流程，包含哪些流程、流程之间的关系、每个流程中包括哪些活动、每个活动涉及到的岗位。企业的作业流程首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图形式。对企业而言需要定义关于业务流程图的描述标准，大家采用相同的图例来描述，便于管理。

业务流程图的优点 :

■ 绘图的过程,实际上是作业流程条理化的过程

■表达形象直观,易于和用户交流,易于项目组内部交流调研的结果,需要得到用户的认同,这就需要和用户交流调研的结果,交流的文档要通俗、易懂, 不能采用专业术语。

■可以作为培训实施人员与技术服务人员的文档

业务流程图的缺点 :

■对高层管理人员的实际需求调查的不清楚.这一方面是由于用户没有接触过计算机, 对采用计算机后的管理会是什么样子?计算机能够完成当前手工操作的哪些内容?能够作哪些现在手工无法完成的工作等等没有清楚的概念,因此用户无法将这些问题反应出来.另一方面说明分析人员没有经验,对原始材料挖掘不深,不能从用户提供的材料中提炼处来用户的真正需求,不能找到当前管理中的问题。

■对各种业务之间的总体关系没有表达出来.采用直式业务流程图可以将企业的每一种业务的处理流程清楚地表达出来, 但是各业务之间的联系却没有表示出来,单看一种业务的流程图很清楚,但是却不能综合在一起,没有整体的概念,作为需求分析的文档,在这方面表达的不够完整。

■在不利用工具的情况下,画法烦琐。图形可以将流程描述的很清楚，但是还要附加以一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述出的内容，需要用文字进行详细描述。

3）企业的数据模型

即企业中的信息载体有哪些？以及对这些信息载体的详细刻画，包括企业的各种单据、帐本、报表的描述。在需求报告中，应该将单据的描述格式化，需要描述的内容包括：

单据的用途，即单据用在什么地方？

单据的格式：需要明确的画出来，并有实际的有数据的样例，能够具体直观地说明问题； 单据中的数据项的具体描述：长度、类型、计算生成方法、约束条件等；

单据的数据项是由哪些不同类型的角色来填写地，包括用计算机可以填那些数据项。单据中哪些数据是必填的，哪些是可以不用填的。

单据流量：平均每天产生多少条记录，高峰期的数量；

单据的分类：可以从多个角度上进行分类，如：按业务类型来分类（采购/销售/生产），按生成的方式来分类（手工录入型/自动生成型），按格式变化的频繁程度来分类（易变型/稳定型），按表现形式来分类（列表型/卡片型）等等。

单据之间的关系：引用关系等等。

同样对于需要的报表与帐本也可以参照上面的条目进行详细的刻画。

4）企业的商务规则模型

即企业中的商务规则有哪些?这些规则用在哪些地方? 商务规则可以从影响的范围划分为2类：一类是局部的规则，如不允许出现负库存，一类是整体的规则，如对所有的物料管理到批次。商务规则一般是隐藏在功能模型或者流程模型中，不需要单独描述，但是有些复杂的商务规则是需要单独抽取出来描述，如企业的各种单据记帐的商务逻辑，5）企业的功能模型

功能需求是用户的最主要的需求，对用户功能需求的描述可以采用文字描述也可以采用语言加图形的描述方式，只要能够将用户的需求描述地完整、准确、易于理解即可。对功能需求比较复杂的系统（如超过10个功能项），可以先描述一个概要，对简单的系统可以直接进行详细描述。对于用户的功能需求要进行分类，分类的方法应便于用户理解，如按照用户的部门设置情况，进行描述每个部门的需求，这样也便于组织用户进行评审。以下是分类方法的举例：

按部门分类：如采购科、销售科、计划科、生产车间、财务科、统计科、总经理等； 按功能类型分类：如单据录入、单据审核、单据查询、记帐、帐本查询、统计报表、系统维护等。

对功能需求的分类在不同的层次可以采用不同的方法。

对每一项功能应有一个功能编号，以便于与功能规格说明书中的章节进行对应。对每一项功能的描述，应指明用户的输入(input)、处理方法（process）、系统的输出(output)及对此项功能的其他要求。功能需求还应注明使用此功能的岗位。对系统管理员要求的特殊功能可以在此注明，非特殊要求可以在需求分析规格说明书中详细论述。如用户权限可分级，要有操作日志等。

功能需求与性能需求是密不可分的，笼统的性能需求没有任何意思，必须具体到某项功能需求上来，这是分析人员在分析系统时容易忽略的一项。

对上述的5个基本元素可以将他们描述为一个五元组〈组织，流程，功能，数据，业务逻辑〉，对于用户来讲，他们习惯于从组织维来看待系统，即某个部门有哪些岗位，每个岗位参与了哪些流程的哪些活动（功能），在某个功能上操作了哪些数据，对这些数据进行了哪些逻辑处理；对于开发人员习惯于从功能维来看待系统，即某个功能操作了哪些数据，对这些数据进行了哪些逻辑处理，这个功能属于哪个流程，可以由哪些岗位来使用；对于设计人员可能习惯于从数据维来看待系统：即系统中有哪些数据，在这些数据上可以做哪些处理，这些处理用OO的思想来看即是对数据对象的操作。

对以上的5个基本元素进行描述实际上就是系统建模的过程，为确保模型的可操作性，除了上面的5个基本要素外，还需要重点描述的内容有：

（1）新系统对应用模式带来的变化包括对企业的组织结构、作业流程、单据帐本报表等的格式、商务规则等的改变。

（2）新系统的界面模型

用开发工具将用户操作界面快速画出来，使用户心中有数。若时间允许，可将界面原型与数据库表、字段连接起来，真正做出系统雏形，即快速原型法。阅读需求文档的4类读者

需求报告的最终目的是给人来阅读的，所以一定要考虑需求报告的读者群，有4类角色可能阅读企业管理系统的需求文档：

客户与用户业务高层；

用户的中层管理人员与具体人员；

用户IT主管与开发人员，包括设计人员、编码人员、同行的专家；

项目管理人员：包括项目经理、质量保证人员、测试人员、需求管理员、配置管理员、计划人员等等；

不同的读者对文档的阅读需求是不同的，他们关注的信息是不同的。我见过了很多次需求评审的失败（如果做好需求评审我会另外再撰文描述），总结下来我认为和需求描述没有区分读者群是很有关系的。针对上述的4种分类，我们具体的来分析一下每类读者的特点：

（1）客户与用户业务高层

他们关心的企业是系统的目标性需求，关心的是系统总体的功能框架，关心的是系统解决了哪些管理问题，对具体的需求是不关心的，所以给他们阅读的文档应该是从总体上来描述，要高度抽象。由于他们的工作很忙，很难有比较长的时间来读这些材料，所以要简短明了，能够用1页纸说明问题的就要不要用2页纸，而且一般都要给高层进行需求汇报，需要配上语言说明，因此采用PowerPiont片子也就成了一种常用的方法，讲解需求与讨论一般应掌握不要超过1小时。需求人员常犯的毛病是过多地关注了企业的细节性需求，而忽略系统的目标性需求，所以在安排需求获取的步骤上、需求报告的编写上往往没有抓住企业高层最关心的问题、没有抓住根本性的问题，在给企业的高层汇报时当然很难通过评审。

（2）用户的中层管理人员与具体人员

企业的中层管理人员关注的是企业的局部需求，他们要求对自己的负责的局部系统能够有总体的了解，能够和其他的子系统衔接的很好，业务流程很流畅，覆盖了自己需要的所有业务流程，能够通过系统起到控制作用就行了。具体的操作人员更关心自己的的哪些活动是否在系统中都能处理，软件是否可以很容易地操作，他们关注的焦点更具体，要求更直观。所以对这类的读者可以通过比较详细的文档来描述需求了，当然应该以他们习惯的思维方式来描述，不能从开发人员的角度来描述。我看到过很多几百页的需求文档给用户去阅读、去评审，结果要么用户不置可否，要么直接讲看不懂，为什么呢？一是开发人员在文档中分子系统、分模块、分功能点一层深入下去描述，不符合用户的思维习惯，他们希望能够从业务流程、业务活动的角度来考虑问题，而不是功能；二是太多了，用户也没有时间静下心来去消化、吸收如此多的文档，需求毕竟不是小说，能够那么吸引读者。

（3）用户IT主管与开发人员

包括设计人员、编码人员、同行的专家大多数分析人员可能最擅长的就是些写这类的文档了，往往也是那这类的文档给所有的读者看，其问题我们上边都说了，这里我们就不赘述了。需要注意的是在描述需求时候传统的做法是以功能为主线，来展开描述，实际上如果是以数据为主线来描述需求也是一种很好的办法，在我们上面谈到的五元组中，从数据的角度来分析系统可以更容易实现向OOA、OOD的切换。

（4）项目管理人员：

包括项目经理、质量保证人员、测试人员、需求管理员、配置管理员、计划人员等等把拿给开发人员看的需求文档给管理人员看，这也是分析人员常犯的毛病。管理人员实际上最关心的是需求列表。在此基础上项目经理、质量保证人员可以据此来进入项目策划过程，测试人员可据此进入测试策划过程，需求管理员、配置管理员可以识别配置项制定相关的活动计划。没有这张表管理人员就很难高效地开展他们的管理活动，也就谈不到最基本的需求复用了。在上述的表中，需求的优先级是很重要的一列，对项目经理进行项目管理的平衡决策是很重要的，实际上需求的优先级可能比需求本身更重要。需求描述的表示技巧

上面我们谈到了，需求文档是人与人之间交互的文档，是不同类型的人之间交互的文档，因此需求文档的可读性是一个很重要的方面，为了提高文档的可读性可以借鉴下面的一些做法： 在文档的描述中，适当运用链接，增强文档的可读性；

多用穷举的方式，以便于发现遗漏的需求；

通过适当的换行来提高可读性 ；

采用黑体、斜体、下划线、颜色等多种方式来突出重要内容；

定义标准的术语，以减少二义性，减少文档的页数；

软件测试管理方法 篇3

【关键词】心理测试方法；企业人力资源管理；应用

引言

心理测试的重点在于对一个人的品德、气质与态度和能力的测评，但是如何运用测评的结果，对其做出合理的解释是心理测试方法的应用难点。霍格雷夫测试公司曾对100家大公司进行过调查，在73家回复该项调查的公司中，有59家企业的人力资源管理采用过心理测试。

一、心理测试概述

心理测试主要是指通过一系列的手段，将人的某些心理特征进行量化处理，从而获得人的智力水平和个性方面的差异。心理测试方法是一种客观的、科学的选择方法，其可以被有效应用于现代企业中的招聘体制以及员工的测评考核当中[1]。

心理测试是对行为的间接性测量，在测量过程中主要针对一组行为样本，通过标准化的测验方法，力求得到客观化的测量结果。因此，心理测试的基本特点可以概括为间接性、标准化和客观化的行为测量方法。

心理测试的种类主要包括认知和人格两个方面，认知方面的测试比较著名的有斯坦福成就测试、斯坦福-比奈儿智力测试以及一般能力倾向和特殊能力倾向测试。

二、心理测试方法在企业人力资源管理中的应用

1.心理测试方法在企业人力资源管理中的应用意义。通过运用心理测试方法可以创新、发展和完善人事测评理论，增进人岗的匹配程度，加强人的职业适应性，进而提高职业活动的效率和职业培训的效益。其次，心理测试在人事测评中具备的突出优势包括迅速有效、科学合理、公正公开以及量化可比等，其符合现代企业人力资源的制度标准。

随着现代化企业的发展，对于人才的需求也越来越高，心理测试方法可以有效测量出被试者的特殊化才能，了解其具有的潜力特征以及职业态度等。因此，心理测试方法应用于现代企业人力资源管理过程中是十分必要的[3]。

2.品德测评在企业人力资源管理中的应用。员工品德素质是影响企业绩效的直接原因，品德是个体思想、政治、道德、法制、个性以及心理等方面所表现出的稳定行为特征与倾向的总和，其直接影响到个体在企业中的能力表现和绩效水平等，这也是现代企业人力资源管理进行人事测评中的重要依据。

问卷法测评品德是现代企业人力资源管理中比较常用的、方便的高效测试方法，常用的具有代表性的问卷为16PF，即卡特尔16元素个性问卷，其中包含的因素有乐群性、聪慧性、稳定性、持强性、兴奋性、有恒性、敢为性、独立性和自律性等16个典型的品德特征，即可以反映出员工对企业的忠诚程度，确定其与企业文化和相关岗位的适应程度。

3.气质与价值观测试在企业人力资源管理中的应用。气质与价值观测评关系到个人的气质、价值观和兴趣三个方面。职业价值观和职业兴趣是指在职业活动方面的表现形式，是复杂的职业特点与个人兴趣与个人价值观的多样性相互联系后所表现出的一种特殊的心理现象。在与现代企业人力资源管理的结合过程中职业兴趣测评的作用较为突出。

在企业人力资源管理实际测评中，通过霍兰德职业兴趣检测量表对职员进行职业兴趣测评，从而判断员工兴趣取向与工作绩效和个人能力展现之间的关系，并结合测评结果有针对性的配置资源。

4.能力测试在企业人力资源管理中的应用。能力测评在企业人力资源管理中的应用主要包括两个方面，一方面是判断员工的基本能力水平是否符合企业岗位需求，另一方面是判断个体是否具备长期发展的特殊潜能，是判断个体是否具备成功素质的基本方法。企业在进行人力资源管理的过程中，能力测试既可以作为一种基础能力的测评方法与其他心理测试方法结合使应用于现代企业人力资源管理的招聘体制当中，作为一种考评手段，同时能力测评方法也可以作为一种特殊能力考核方法，用于绩效考评分析和晋升依据标准等。

结论

综上所述，通过分析心理测试的基本特点和方法，说明了心理测试的作用与意义，并进一步探讨了心理测试方法在现代企业人力资源管理中的应用情况。心理测试方法本身具备一定的科学性和客观性，其可以有效测量出员工的综合素质和能力素质，同时还可以为企业的工作绩效考核和职位晋升等环节提供依据。

【参考文献】

[1]邹燕.供应链管理模式在我国企业人力资源管理中的应用初探[D].北京物资学院，2010.

[2]李顺.胜任力研究在A物流企业人力资源管理中的应用初探[D].上海海事大学，2007.

[3]陈梓松.平衡计分卡在企业人力资源管理中的应用研究[D].广西大学，2006.

[4]陈洪.胜任特征模型在供电企业人力资源管理中的应用研究[D].华北电力大学（北京），2005.

软件配置管理简化实施方法 篇4

随着科技的不断发展, 软件项目的复杂性与集成度越来越高, 项目的成败在很大程度上取决于对其开发过程的控制, 包括对质量、源代码、进度、资金、人员等的控制, 有效的过程必须有科学的管理方法, “软件配置管理”是通过技术或行政手段, 对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。实践证明, 软件配置管理是一套规范、高效的软件开发管理方法, 同时也是提高软件质量的重要手段。

1.1 实施软件配置管理, 是提高效率和质量的必要手段

软件研发中出现的每一个问题, 必须及时定位、修改、更新和记录, 配置管理过程中的记录、报告和版本控制, 通过问题跟踪和追溯, 能加快问题的定位和修复, 并最大限度减少缺陷和错误的发生以及再次发生;同时, 在软件编码过程中, 使用配置管理工具, 能够较好的避免因并行开发、多重维护带来的版本混乱、重复编码等问题, 清晰的配置管理过程, 在节约人力的同时, 提高了产品质量。

1.2 实施软件配置管理, 有利于单位建立知识库

软件代码是软件开发人员脑力劳动的结晶, 也是软件开发单位的宝贵财富, 长期开发过程中形成的各种代码对象就像一个个零件坯一样, 是快速生成系统的组成部分。实施配置管理, 能够对各人的有用对象进行管理, 把其使用范围扩大到单位级, 进行规范化并加以说明和普及, 建立单位级的代码对象库;在配置管理中, 形成完整的开发日志及问题集合, 以文字方式伴随开发的整个过程, 不依某个人的转移而消失, 有利于单位积累业务经验, 无论对版本整改或版本升级, 都具有重要的指导作用。

1.3 实施软件配置管理, 能够降低成本, 节约费用

通过软件配置管理, 可以对不同阶段软件代码版本进行管理和跟踪, 建立代码知识库, 提高代码的重用率, 同时最大限度地共享代码, 便于进行新版本或类似功能的开发, 减少再开发的成本, 提高开发效率, 缩短开发周期;通过配置管理, 建立开发管理计划和规范, 共享最新文件和代码, 当项目成员跨地域分布时, 能够实现协同有序, 互不干扰而又不失去控的异地工作, 从而节约大量的旅差费用。

1.4 实施软件配置管理, 是规范管理的要求

通过建立科学的配置管理流程, 将大量的文档和代码等知识财富统一标识, 按阶段进行规范化管理, 避免随意保存在项目经理和软件工程师各自的机器里, 因硬盘故障或人员离职造成数字财富因缺乏必要的配置管理而白白流失。能够应对人员离职、版本混乱、加快问题的定位和修复;通过配置管理规范软件研发各阶段的文档, 进行有效的质量记录和文档管理, 保证每个使用者都能得到正确的版本, 在提高项目研发效率的同时, 也为企业积累了组织级财富, 便于今后的项目共享;软件项目的研制过程是随项目的规模以指数上升, 只有在项目研制之初, 制定项目开发和管理计划, 并在研制过程中, 依照计划实施, 才能避免项目研制过程中的盲目性;代码回溯是软件编制过程中经常发生的, 使用工具进行规范化的配置管理, 每天记录当天代码修改情况, 规范文档和代码每天的版本, 使工作或代码回溯成为轻松便捷的事。

2 简化实施软件配置管理的策略

软件配置的主要工作包括:建立配置管理机构和配置库 (即软件开发库、受控库、产品库, 又称软件三库) 、制定配置管理计划、基线控制、出入库控制、更改控制、配置状态记实、配置审核。本文重点介绍综合性科研单位的软件配置管理工作的简化实施。

2.1 建立配置管理机构和配置库

在项目设计开发期间, 应建立相应的配置管理组织 ( 配置管理委员会或配置管理小组) , 专门负责配置管理工作。项目组应指定专人 (配置管理员) 处理配置管理事务。

配置库也称为软件“三库”, 是软件配置管理机构的组成部分, 包括:开发库、受控库、产品库。开发库存放各开发阶段产生的尚未通过评审的程序、文档等电子版本或纸制资料, 一般由项目组建立并维护;受控库存放已通过测试或评审且作为阶段性产品的软件配置项集合, 包括程序和文档, 一般由研制管理部门 (或质量管理部门) 建立和维护, 受控使用;产品库存放已定型 (鉴定) 且供交付、生产、检验验收的软件配置项集合, 包括源代码、可执行程序、数据和文档的电子版或纸制资料, 一般由组织的技术档案管理部门建立和管理。

三库可以借助专门的配置管理软件建立, 也可以以电子或物理形式建立。例如:受控库可以是一系列电子文件夹, 产品库可以是一组文件柜。如表1 所示。

2.2 制定配置管理计划

配置管理计划的目的在于对所开发的软件规定各种必要的配置管理条款, 从而保障产品质量。内容包括:说明配置管理角色和职责、计划纳入配置管理的配置项、计划的基线时间和内容、配置库的建立方式和授权、配置状态记录和统计计划、更改和版本控制, 并确定项目标识、文档标识、程序和产品标识、版本标识等。

对基线的管理是配置管理的重点内容。基线是软件文档或软件代码的一个稳定版本。是被正式确认并作为今后研制生产、使用保障活动的基准。已形成基线的关键文档, 虽然可以修改, 但必须以一个特殊的、正式的过程进行评估, 确认每一处修改。软件开发项目的配置管理基线包括:功能基线、分配基线、设计基线、开发基线和产品基线。在实际应用中, 根据项目的规模和实际研发情况, 可以只划分功能基线、分配基线和产品基线。基线对应的标志性文档如表2, 每一种基线以通过一定级别的评审后建立。

2.3 配置控制

开发库出入库较频繁, 主要由项目组控制。通常配置控制主要是对受控库和产品库的控制。为了简化实施, 只能涉及基线的配置项目进行控制。

2.3.1 基线控制

在确立基线的标志性评审通过后, 及时将基线文件入库, 此后, 若有对基线文件的使用和修改, 应及时记录并向有关人员发布最新版本。

2.3.2 出入库控制

一般在基线建立后、变更前后和重要事件前后, 要记录配置项出入库。配置项出入受控库或产品库应当填写《出库单》和《入库单》。

2.3.3 更改控制

被更改的源代码和相关文档必须正式取自配置管理的受控库或产品库, 更改后重新入库并填写《配置变更报告单》, 版本的变更, 也应进行记录。

2.3.4 配置状态记实

记录并报告受控软件配置管理项的现行状态和历史。在实施配置变更处理的过程中, 配置项的状态分为:变更中、有效、无效。配置管理者应在一个重要阶段结束时, 及时汇总《配置状态记录单》。

2.3.5 配置审核

在项目研发完成一个阶段或在产品交付前, 应进行功能配置审核和物理配置审核, 功能配置审核以确定和保证配置项的完整性;物理配置审计以检查程序与文档的—致性、文档与文档的—致性、交付的产品与任务书要求的—致性以及与标准规范的—致性。完成审核后, 应填写《配置审核单》。

2.3.6 配置总结

根据配置管理情况, 一般在项目完成时, 编写配置管理报告, 也可以在研制总结中进行配置管理总结, 内容包括:配置管理情况综述、用户组划分及权限分配、配置项记录、基线记录、入库记录、出库记录、变更记录、审核记录、备份记录等。

3 结束语

专业软件开发单位的软件配置管理工作, 一般应达到软件研制能力成熟度模型 (CMM) 3 级或以上标准, 故一般采用专业的配置管理软件实现;对于实施质量管理体系的综合性科研单位的配置管理, 一般达到软件研制能力成熟度模型二级标准即可, 重点记录基线形成和变更、大阶段的配置管理状态和审核, 以及相应的出入库, 可以采用一些版本管理软件辅助实施, 同时制定一系列规则, 以人工辅助部门级配置管理工作。

注:文中提到的配置表单和文档表单, 可参考相关标准中的格式。

摘要：软件配置管理是通过技术或行政手段, 对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。配置管理的主要工作一般包括:建立配置管理机构和软件三库、制定配置管理计划、基线控制、出入库控制、更改控制、配置状态记实、配置审核。根据项目的具体情况, 配置管理的实际工作内容不同。

关键词：软件配置管理,配置管理,软件三库,配置管理简化实施

参考文献

[1]陈焱, 李勇, 韩铁军.配置管理在软件系统开发中的作用[J].自动化指挥与计算机, 2012 (04) .

[2]冯济舟.软件配置管理典型问题的研究与思考[J].航天标准化, 2013 (03) .

[3]刘旭奕.基于GJB5235的软件配置管理方法初探[J].标准介绍, 2011 (02) .

[4]高贤志, 戴恒毅.导航装备软件配置管理方法研究与实践[J].装备质量管理, 2012 (08) .

软件测试管理方法 篇5

汽修汽配管理软件系统对故障的确认有以下四种方法：

1.值域判定法

当控制电脑接收到的输入信号超出规定的数值范围时，自诊断系统就确认该输入信号出现故障。例如：某车水温传感器设计在正常使用温度范围-30—120℃(或范围更大些)内，输出电压为 0.30—4.70V，所以当控制电脑检测出信号电压小于0.15V或大于4.85v时就判定水温传感器信号系统发生短路或断路故障。

2.时域判定法

当控制电脑检测时发现某一输入信号在一定的时间内没有发生变化或变化没有达到预先规定的次数时，自诊断系统就确定该信号出现故障。例如：氧传感器在发动机达到正常工作温度，控制系统进入闭环后，电脑检测不到氧传感器的输出信号超过一定时间或者氧传感器信号在0.45V上下没有变化的情况已超过一定时间，自诊断系统就判定氧传感器信号系统出现故障。

3.功能判定法

当控制电脑给执行器发出动作指令后，检测相应传感器的输出参数变化，若传感器输出信号没有按照程序规定的参数变化，就确认执行器或电路出现故障。例如：一般汽车EGR系统装有EGR阀高度传感器，用以检测EGR阀是否正常工作。但有的汽车并没设置EGR阀高度传感器，当控制电脑发出开启EGR阀命令后，通过检测进气压力传感器MAP输出信号是否有相应变化，也可以确定 EGR阀有无动作，若没有变化，则确认EGR阀及电路有故障。

4.逻辑判定法

控制电脑对两个具有相互联系的传感器进行数据比较，当发现两个传感器信号之间的逻辑关系违反设定条件时，就断定其一定有故障。例如：控制电脑检测到发动机转速大于某个转速时，节气门位置传感器输出信号小于某个值，则判定节气门位置传感器出现故障。

手机应用软件测试方法概述 篇6

关键词：外部质量；内部质量；手机应用软件；测试

中图分类号：TP311.53

1 手机软件测试背景

随着科技的进步，众多的手机应用软件像雨后春笋般地涌现出来，这些软件不仅丰富了手机的功能，也为人们的生活提供了便捷，并且已经从单一的通讯工具发展成为了个人信息收集和处理的移动平台，然而，这些软件在为人提供方便的同时，由于其本身所存在的问题，也会给人们带来无法估量的损失，例如：个人资料泄露、个人银行信息泄漏、信息丢失等，如果能提前发现这些问题，便可以降低其带来的经济损失。所以为了能够提早发现手机软件中存在的问题，对其进行软件测试便是唯一的方法。然而手机应用软件与传统软件存在着很大的不同，如何能够有效、正确和便捷地对手机应用软件进行测试是急待解决的问题。本文主要结合GB/T17544-1998《信息技术软件包质量要求和测试》对手机应用软件测试的类型和方法进行总结和概述。

2 手机应用软件测试概述

2.1 手机应用软件与传统软件的比较

与传统应用程序相比，手机应用软件的不同主要表现在运行平台和运行网络两个方面。

（1）运行平台的不同。传统软件主要支持Windows、IOS和Unix三款操作系统，软件运行平台较单一，软件版本较少，然而与传统软件相比，手机应用软件支持Symbian、Palm、BlackBerry、WindowsMobile、Android和iOS六款操作系统，软件版本较多，测试复杂性和重复性较大。

（2）运行网络环境的不同。传统软件主要运行在联通、电信和移动三家运营商提供的上网服务，网络环境差异性较小，然而与传统软件相比，手机应用软件需支持2G网络：GSM、CDMA、3G网络：WCDMA、TD-SCDMA、CDMA2000和Wifi，网络环境种类较多，测试难度较大。

2.2 手机应用程序测试标准和流程

目前手机应用软件测试主要遵循的标准的是由信息产业部电信研究院牵头制定的YD/T1438-2006《数字移动台应用层软件功能要求和测试方法》，该标准是以大量测试实验为基础上，综合移动通信技术的特点而制定的测试技术规范。除此之外，从软件测试的角度出发，手机软件测试还应遵循GB/T17544-1998《信息技术软件包质量要求和测试》中规定的要求。所以主要对手机应用软件的测试也主要从功能性、安全性、可靠性、可移植性、效率和易用性六个方面进行测试。其中功能性主要测试手机应用软件功能实现的正确性和对软件设计文档的依从性；可靠性主要测试软件在错误输入或不稳定网络环境下，软件能够正常运行的能力。

手机应用软件测试虽然属于软件测试的一种，所以针对传统应用软件的测试过程也适用于手机应用软件的测试，测试过程包括需求分析、计划、实现、执行、评审5个过程。

3 手机应用软件测试类型概述

3.1 功能性测试：

（1）功能模块测试：功能测试的主要目的是发现软件实现的功能对软件设计文档或行业标准的满足程度。在进行功能测试时，首先要结合软件的需求分析、设计文档或行业标准等文档对软件功能的输入、输出数据进行分析，在此基础上确定功能测试需求，通过使用等价类划分法、功能划分法等测试用例设计方法进行测试用例的设计，最后通过执行测试用例来发现软件中存在的问题。

（2）功能交叉测试：随着手机智能化程度的不断提高，基于手机的应用程序也逐渐增多，由于各种程序对手机硬件资源的需求不同，所以便会导致多个程序同时争夺一个硬件资源的情况，这种情况可能会导致各应用程序因为争夺资源而产生死锁现象，致使手机操作系统崩溃，所以为了避免这种情况的发生，在进行功能测试时，需要進行功能交叉测试，通过在执行被测功能的过程中，执行其他应用程序的方法来发现和预防该问题的发生。

3.2 安全性测试

手机应用软件中存储的数据信息如：个人信息、账户信息等，已经成为了众多黑客和不法人员窥探的资源，这些人通过手机应用程序本身的安全漏洞可以轻松地获得用户存储在手机中的私密信息。所以必须通过安全漏洞扫描工具、应用程序代码分析和功能安全性测试的方法来发现手机应用软件中存在的安全漏洞，对于软件安全性和用户数据信息的保密性具有重要的作用。

3.3 可靠性测试：

随着手机应用软件功能的逐渐增强，人们对手机的依赖程度也逐渐提高，个人重要数据信息、行程信息等数据都被存储在手机上，所以要对手机应用软件的可靠性进行测试，手机应用软件的可靠性测试主要从以下几个方面考虑：

（1）测试手机应用软件避免因为部分功能模块的失效而导致整个应用软件的崩溃的能力；

（2）测试手机应用软件在长时间工作情况下，能够正常工作的能力；

（3）测试手机应用软件在发生崩溃后，能够快速恢复数据和运行的能力。

3.4 兼容性测试：

目前市场上的手机种类、手机操作系统种类较多，手机应用软件运行的硬件环境和软件环境各不相同，这使的手机应用软件可能在不同的运行平台下产生不同的运行结果，这是手机应用软件生产厂商和用户都不想看到的，所以在手机应用软件上市之前就要对其兼容性进行测试，测试过程主要从软件和硬件两个方面来进行。在软件方面主要是通过将软件运行在不同的手机操作系统下来对其功能表现进行评价，在硬件方面主要是通过将手机应用软件运行在不同手机厂商生产的手机上来对其功能表现进行评价。

4 总结

在对手机应用软件进行测试时，可以借鉴针对传统软件的测试过程和方法进行手机应用软件测试用例的设计和测试过程来进行测试，但是与传统软件测试相比，还需另外考虑软件在不同手机操作系统和不同硬件环境下的表现，而且还缺乏相应的自动化测试工具，测试过程较复杂和繁琐。所以如何开发和利用自动化测试工具进行手机应用软件测试方面，还需要进行不断的探索和研究。

参考文献：

[1]贺晓能，薛涛.手机应用层软件的功能要求和测试方法[J].现代电信科技，2007，3.

[2]崔启亮，胡一鸣.国际化软件测试[M].电子工业出版社，2006，4.

[3]朱少民.全程软件测试[M].北京：电子工业出版社，2008，7.

作者简介：张鑫（1985-），男，江南机电设计研究所，研究生，助理工程师，研究方向：软件开发与测试。

软件配置管理过程控制方法研究 篇7

随着计算机技术的飞速发展, 大量应用软件在各种系统或设备中被安装使用, 为提高各种作业流程的自动化水平发挥了重要作用, 可以说, 没有应用软件支撑, 许多系统都无法运行。在实际应用中, 往往需要针对特殊业务需求或作业流程, 定制或开发专用应用软件, 并根据业务需求变化进行适应性改造与完善。该软件一般需要自行研制开发, 由于应用软件开发涉及到规模大小不同、软件关键性等级不同、软件开发运行环境不同、软件开发人员分工和开发能力等多种因素, 在软件开发和应用管理过程中存在问题较多, 有些问题甚至直接影响到业务运转或作业流程的成败。

(1) 软件工程化规范问题。软件项目实施中, 参加软件开发的人员一般由负责设备管理或具体专业的人员参加, 对软件工程化缺乏深入全面的掌握, 只能边学习、边设计、边实现、边修改, 容易产生软件开发阶段划分不准确、文档拟制不规范、软件文档与实际产品不相符、软件测试不周全等问题。

(2) 软件版本控制问题。自研应用软件开发与应用中, 开发者一般同时也是使用者, 开发环境也是运行环境, 开发人员对负责的设备和业务比较熟悉, 对自己开发的软件也比较熟悉, 在使用过程中更容易发现软件存在的问题和缺陷, 因此往往会随意改动软件, 而不提交软件问题申报单和软件更动报告单, 不进行相应的影响域分析, 更动之后也仅仅只做调试, 不经过严格正规的测试, 会造成潜在的软件危险, 甚至可能直接影响到设备安全。

(3) 软件使用管理问题。不按照软件配置管理和使用规定, 从软件配置管理库中提取正确的软件版本, 或者仅办理软件使用审批手续, 但不清理软件运行环境, 不检查软件版本和运行状态, 仍然会出现实际运行软件不是正确版本、不能掌握软件运行环境和运行状态等问题, 最终可能导致软件配置管理的失控。

1 软件配置管理关键环节

软件配置管理的任务是制定软件配置管理计划, 确定配置标识规则, 实施变更控制, 报告配置状态, 进行配置审核, 进行版本管理和发行管理。

软件配置管理是从软件项目开始直至软件退出运行, 贯穿整个软件生命周期的一组跟踪与控制活动, 本质是标识、组织和控制对正在开发的软件修改更动的技术, 以减少软件更动所需的工作量。其重要性在于:“你不控制变更, 变更就会控制你。”而变更是软件开发过程中不可避免的活动。

熟悉并恰当应用软件配置管理工具, 可以很好地管理软件项目, 但在实施中要真正管理好软件项目, 除了技术手段, 如何对过程进行管理更加重要, 需要把握好几个环节, 一是软件生命周期的合理划分, 二是软件更动控制的管理方法, 三是软件运行版本的管理。

1.1 软件生命周期划分与裁剪

完整的软件生命周期包括系统分析与设计、需求分析、概要设计、详细设计、编码与单元测试、部件测试、配置项测试、系统测试、验收移交与保障、软件维护、软件报废。

对具体的软件项目, 不一定包括生命周期的所有阶段, 要根据软件规模、运行环境、开发环境、安全级别等因素综合考虑, 对具体软件项目进行合理的阶段划分和裁剪。

(1) 仅有一个配置项的小规模软件, 如运行在一台设备中的应用软件, 软件设计不需要划分概要设计和详细设计阶段, 软件部件测试阶段也不需要, 但如果软件关键性等级高, 则需要详细划分各个阶段。

(2) 基于集成可视化的组态软件的设备监控软件开发, 不需要考虑软件单元测试和部件测试阶段, 甚至可以将配置项测试与系统测试合并。

(3) 对于大规模和包含多个配置项的软件, 要划分完整的生命周期阶段, 每个阶段都要提供完整的文档和产品。

(4) 对于软件开发的每一个阶段, 都要进行阶段评审, 软件编码与单元测试、部件测试阶段一般只需要内部评审, 其它阶段需要专业机构或专家组织进行评审。软件配置项和系统测试需要第三方测试。对于软件关键性等级高的软件, 各个阶段都要组织专家评审, 必须经过第三方测试。

(5) 各个阶段都要提交相应的产品和文档, 并严格按照软件配置管理要求进行管理。

1.2 软件更动控制

软件配置管理的根本任务就是有效控制软件更动及其产生的影响, 软件更动产生的影响往往是不可估量的, 因为软件代码中一个极小的Bug可能就会造成设备极大的故障甚至灾难。因此, 必须要严格控制软件更动过程, 防止严重故障或灾难性问题的发生。

(1) 软件问题报告。软件开发人员或使用人员通过填写软件问题报告单向主管机构报告发现的问题, 软件问题报告单要准确描述软件问题名称、软件版本信息、提交问题的人员及时间等, 对软件问题来源 (程序、文档、数据库、设备更新等) 、问题现象和原因也要进行详细描述, 并提出修改要求和修改内容。

(2) 软件更动审批。软件开发人员根据软件问题报告单填写软件更动报告单, 说明软件更动类型 (纠错、改进、扩充等) 和更动项目 (程序、文档、数据库等) , 要详细描述软件更动的具体内容, 进行影响域分析, 说明软件更动对设备、其它软件模块或作业流程的影响, 确保软件更动的正确性, 防止产生负面影响。软件更动报告单要经过软件配置管理机构的审查和批准, 方能实施更动, 如果需要, 还应当进行评审, 以确定是否可以更动, 以及更动的内容和方法是否合适。

(3) 回归测试。软件更动后要进行测试, 编写完整的测试用例来测试更动后的软件。通过测试后, 要按照软件配置管理程序履行软件入库、出库与安装运行手续, 以正确使用更动后的软件。

软件更动本身可能比较简单, 比如只修改一条语句甚至一个字符, 但软件更动的管理过程很复杂, 从提交软件问题、更动、测试到运行需要履行多道手续, 有可能还要经过评审。这一过程的工作量远远比修改软件本身的工作量繁重得多, 因此可以有效防止开发人员随意更动软件行为的发生。

1.3 软件使用过程管理

软件使用过程管理, 既要保障操作人员从配置管理库提取正确的软件版本, 还要检查使用人员是否正确使用软件和使用正确的软件版本, 特别是在自研软件较多的情况下, 必须检查软件使用状态。

(1) 软件使用申请。软件使用人员根据设备运行或作业流程, 在一个特定的阶段开始前, 比如每年或每个季度, 或在设备投入使用前进行设备状态检查时, 填写软件出库申请单来申请使用软件, 说明申请使用的理由和需要使用的软件版本, 经过审批后从软件配置管理库提取软件。

(2) 软件安装使用。软件安装前, 要对软件运行环境进行清理, 包括重新安装操作系统、查杀病毒、删除原来运行的软件版本 (或进行备份) , 重新配置软件运行环境, 以保障软件环境的干净和安全。然后根据软件安装运行的操作规程安装使用软件。

(3) 软件版本比对与检查。软件配置管理机构必须要对操作人员安装的软件进行检查, 以确认是否为申请的软件版本, 这个过程非常重要, 防止使用人员只履行手续而不安装软件, 而是继续运行原来的软件, 对于自研软件, 如果不检查, 可能会出现配置管理库与运行版本不一致而最终导致软件版本混乱的问题。对于固化在PLC中且没有更动的软件, 一般不需要重新安装或固化, 但需要进行软件版本的比对检查, 防止意外情况的发生。

2 软件配置管理过程控制措施

软件配置管理本身是一项保障软件完整性和正确性的技术, 通过管理手段进行软件配置管理过程控制, 则是保障软件开发质量, 保证正确和规范使用软件的基础。

2.1 充分发挥软件配置管理机构的职能作用

按照软件工程规范, 成立软件配置管理机构, 设立软件配置控制委员会, 并下设软件配置管理小组, 明确并履行管理职责。

(1) 软件配置控制委员会负责受控库和产品库中各软件项目配置管理组的成立、配置管理计划、基线设置、配置管理项设置、更动申请、产品出入库等工作的审批, 审查各种表单和提交产品的完整性、一致性和完备性, 核实配置管理落实情况, 确保软件与产品库的一致。

(2) 软件配置管理小组在软件配置控制委员会的领导下, 负责软件配置管理的组织计划与协调, 管理软件配置管理专用系统设备工具, 检查软件配置管理履行手续, 对软件配置管理项及其存储介质进行日常维护管理。

2.2 定期清理软件技术状态

(1) 依据软件配置管理库, 建立软件配套表, 清理软件文档和软件版本, 以保证软件文档齐全规范, 软件版本和文档控制号正确。

(2) 通过代码清查分析等方式, 确认和熟悉软件版本、编程结构及编程方法。

(3) 对软件运行环境进行清理, 对具备病毒查杀条件的计算机进行病毒查杀, 检查机器硬件、操作系统和相关系统软件的工作状态、磁盘存储容量、余量, 清理多余文件和数据。

2.3 检查软件配置管理状态

(1) 检查软件配置管理库中的软件状态, 重点清查应用软件的版本号、文档控制号等, 对软件版本的一致性进行检查, 确保软件源程序和执行代码的一致性, 避免入库源代码与执行代码不对应。

(2) 清理系统应用软件更动情况, 检查软件问题报告、更动报告、回归测试报告等入库情况和软件配置库的完备性。

(3) 对配置管理库中软件配置管理情况进行审计, 保证程序与文档、文档与文档及产品与要求的一致性符合软件工程化技术标准要求。

2.4 软件出库安装和运行检查

(1) 检查应用环境中所安装的操作系统、参数设置与软件用户手册要求是否一致。

(2) 检查应用环境中各系统软件安装、参数设置与软件用户手册的要求是否一致。

(3) 对所有纳入配置管理的软件进行出库安装和运行检查, 逐个安装应用软件并运行检查, 检查各软件功能和性能, 考察软件的正确性和稳定性。

2.5 对嵌入式软件进行比对分析

针对嵌入式软件随设备固化、运行状态隐蔽等特点, 进行出库比对, 重点从运行版本与出库版本的一致性、参数设置的一致性等方面进行比对分析, 确保软件运行稳定可靠。

3 结语

本文针对自研应用软件开发与使用管理中存在的问题, 分析讨论了软件配置管理过程中需要注意的几个环节, 总结了软件配置管理的过程控制方法和有效措施, 以保证软件工作规范有序、软件版本正确、性能稳定、软件开发符合规范要求、软件使用和更动过程受控, 从而有效保障了软件在生命周期内状态的完整性、一致性和可追踪性。

参考文献

[1]邓成飞, 李洁.软件工程管理[M].北京:国防工业出版社, 2000.

[2][美]ROGER S PRESSMAN.软件工程:实践者的研究方法[M].梅宏, 译.北京:机械工业出版社, 2002.

基于看板管理方法的敏捷软件开发 篇8

软件开发项目管理从最早的传统项目管理软件工程期到近年的迭代模型时期,最后到目前的敏捷软件开发时期。敏捷软件开发的成功五项因素分别如下。

(1)建立自组织团队。传统的管理方式具有命令和控制的特点,经理制定目标和计划,团队负责完成,发挥不出员工的创造力,影响了企业的效率。软件开发的敏捷开发要求员工自我管理,个人控制时间和目标,员工能参与流程和项目决策。

(2)用户故事在需求管理中的应用。软件开发企业最大的敌人不是用户,而是变化。瀑布模型难以适应目前软件市场需要,因此软件开发工作要取得用户的参与,顺应市场的变化。

(3)用户故事的度量,它能为产品投资收益提供估计结果,辅助产品决策。对故事点大小讨论时,能鼓励团队成员重复讨论,充分理解需求。故事点度量方式一致,提高统计团队工作效率。

(4)持续集成。它能提高项目构建自动化程度,将人力成本更多投放到开发任务。项目更有可见性,构建结果更加丰富,一目了然。团队对开发产品更有信息。

(5)掌握迭代,为员工提供稳定的生活节奏,保持一致的周期循环流程,沟通过程中控制时间。

(6)坚持反馈和改进,了解自身情况,改善团队效率。

精益生产的目标为提高质量和消除消费。看板原则要求生产降低库存量、降低生产周期、生产基于交叉培训和单元并对过程进行持续改善。如同超市进货一样,当货架上货物少于设定值,供货商会及时将其填满。将看板管理与敏捷软件开发结合起来,能够达到效率和质量的有效结合,软件产品周期频繁,能达到按天发布级别。

2 RCOM项目看板方法流程设计

增量迭代开发开发流程存在着三点问题。

(1)每个迭代的用户故事较多,产品经理和开发工程师认为很多功能没有价值,而项目经理认为需要跟踪的项目较多。

(2)对于为期四周的迭代观念不统一,部门不同,期望值不同,测试人员认为时间不充分,产品经理认为需要等待太长时间。

(3)部门之间缺乏协作,缺乏透明的项目进展和进度,太多时间花费在流程上。敏捷软件开发有三个典型流程,分别XP、Scrum及看板,经过比较,看板原则可以解决迭代用户故事较多的情况,对于规模小及优先级别高的用户故事能够迅速完成,并满足产品经理对产品的预期。

2.1基于看板管理的敏捷软件开发流程方案设计

看板一般应用于汽车生产等工业领域中,在敏捷软件开发中看板管理只是理论上行得

通,但是在实际上还缺乏经验。而且其受到产品特点、客户差异及企业文化的影响。其流程主要为,

(1)定义并可视化流程。

(2)限制WIP数量,流程可视化于物理板能够让项目透明,让团队对目前的任务充分明确。限制WIP数量则能让团队在思考时排除干扰,提高个体效率,项目工作不以来时间计划,而是取决团队能力。

(3)拉动式生产,每个团队成员只需要对自己环节加以关注,等待任务-完成工作-到下一环节等待区。这种方式推动了产品开发前进步伐。

2.2看板流程准备和实施

(1)是动员和人员培训,先获取领导层的理解和信任,再向所有员工培训敏捷开发和看板方法,最后,每个部门进行讨论。

(2)制定需求管理环节,产品经理提出产品需求,创建用户故事,技术团队估算用户故事工作量。通过需求分析,工程师能够获取信息,完成研发工作,产品经理全程辅助开发和测试,解答相关问题。

(3)开发流程改造,主要变化在对程序代码的管理方式进行改变,主要有主干和分支两种。

(4)测试流程改造,主要表现为两个方面,一方面提高系统自动化测试率来加快回归测试的进度,另一方面增加测试环境满足功能测试需求。

(5)项目管理流程的建立。

2.3看板流程的实施

当所有准备工作完成之后,看板方法第36增量迭代之后,可以正式实施。产品经理将用户故事进行排列再制成任务卡,贴在用户故事一列,完成需求分析会议。开发组建立功能分支进行开发,测试组应用功能测试环境对用户故事进行测试,直到产品发布。团队成员每天早上聚集看板附近,明确自己的任务,下班前,项目经理将每天的任务卡状态变化汇总。敏捷流程要求强调团队自组织和员工自我管理,但是不可忽视项目经理的作用,项目经理能够组织人员,梳理工作节奏,保证沟通流畅,促进项目进展。

3看板方法效果分析

在对用户故事完成效率统计,并对超时任务进行反思和改进之后,回顾看板流程管理经验,总结建立自组织团队时,应该考虑建立流程、理顺沟通方式、改善管理风格、制定度量标准四个方面问题。从看板流程团队角色视角分析,就项目经理来说,虽然团队沟通节奏加快,但是需要针对需求变更的灵活、用户故事的调整,适应变化和跟踪进度。就企业运营角度来看,看板流程比增量迭代开发,能实现商业价值,流程改造增加来了沟通,工作更透明、工程师时间自由,优势大于劣势,是一个成功的尝试。

摘要：随着互联网技术以及信息技术的发展,我国的软件市场逐渐庞大,企业为了在软件市场中取得一席之地,必须要促进软件生产的效率、降低软件缺陷和生产成本。本文立足于敏捷软件开发和精益开发方法,研究了看板方法在敏捷软件开发中的作用,得出看板方法敏捷实践可以培养团队、兼顾流程效率及团队成员的自我管理的需要,希望具有借鉴意义。

关键词：看板管理方法,敏捷软件,软件开发,精益生产

参考文献

[1]匡松,周启海,陈森玲等.敏捷软件开发的认识偏误与推广瓶颈浅析[J].计算机科学,2007,34(12):294-295,303.

[2]徐照兴,杨水华.敏捷软件开发过程中重构技术的研究[J].煤炭技术,2012,31(11):223-225.

[3]芮雄健,王忠民.基于敏捷软件开发方法的基金管理信息系统开发[J].计算机应用,2004,24(11):162-165.

[4]夏显鄂,梁洪峻.敏捷软件开发与计划驱动开发的概述比较[J].计算机工程与设计,2007,28(16):4035-4037,4062.

大型系统软件项目管理的方法研究 篇9

1.1 软件项目管理的概念

从概念上讲, 软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成, 而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上, 软件项目管理的意义不仅仅如此, 进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力, 企业的软件开发能力越高, 表明这个企业的软件生产越趋向于成熟, 企业越能够稳定发展 (即减小开发风险) 。

软件项目管理的根本目的是为了让软件项目尤其是大型项目的整个软件生命周期 (从分析、设计、编码到测试、维护全过程) 都能在管理者的控制之下, 以预定成本按期、按质地完成软件交付用户使用。

软件项目管理的内容主要包括如下几个方面:人员的组织与管理, 软件度量, 软件项目计划, 风险管理, 软件质量保证, 软件过程能力评估, 软件配置管理等。

1.2 CMM与CMMI

1.2.1 CMM的由来

CMM是软件过程能力成熟度模型 (capacity Maturity Model) 的简称, 是卡内基一梅隆大学软件工程研究院为了满足美国联邦政府评估软件供应商能力的要求, 于1986年开始研究的模型, 并于1991年正式推出了CMM1.0版。CMM自问世以来备受关注, 在一些发达国家和地区得到了广泛应用, 成为衡量软件公司软件开发管理水平的重要参考因素和软件过程改进事实上的工业标准。

CMM的评估结果是目前世界上公认的软件产品进入国际市场的通行证。中国软件要国际化, 软件企业必先规范化和规模化, 提高软件过程能力, CMM为企业达到目的指出了一条有效途径。CMM也为应用单位和管理部门提供了选择, 同时给予了管理软件承包商一种良好的手段。

1.2.2 CMM与ISO9000

国际标准化组织的质量管理标准ISO9000与CMM均可作为软件企业的过程改善框架。CMM仅仅适用于软件行业, 而ISO9000的适应面更广, 实际上ISO9000:2000版标准和CMM遵循共同的管理思想, ISO9000:2000版 (ISO9001) 标准已经彻底解决了94版的制造业痕迹较重、标准按要素描述难于在软件行业实施的问题。

就内容来讲, ISO9001不覆盖CMM, 也不完全覆盖ISO9000。一般而言, 通过ISO9001认证的企业可达到CMM2级或略高的程度, 通过CMM3级的企业只要稍做补充, 就可较容易地通过ISO9001认证。粗略地说, ISO9001近似于CMM2.5级。

1.2.3 CMMI

CMMI是卡内基梅隆大学2001年9月推出的比较成熟的系统工程和软件工程的集成成熟度模型 (Capability Maturity Model Integrated) 。与原有的能力成熟度模型类似, CMMI也包括了在不同领域建立有效过程的必要元素, 反映了业界普遍认可的“最佳”实践:专业领域覆盖、软件工程、系统工程、集成产品开发和系统采购, 集成的产品和过程开发以及采购, 主要是配合软件工程和系统工程的内容采用。

CMMI的阶段表达方式继承了CMM的思想方法, 将所有的过程域依照5个成熟度等级来组织, 从低到高分别为:初始级 (Initial, 第1级) 、管理级 (Managed, 第2级) 、定义级 (Defined, 第3级) 、定量管理级 (Quantitatively Managed, 第4级) 和优化级 (Optimizing, 第5级) 。如图1所示:

1.3 国防专用软件CMM二级介绍

国防专用软件要求其具有极高的保密性, 可靠性和有效性。国防专用软件CMM二级实施规范, 定义了软件工程化管理涉及到的过程、活动与任务, 是实施贯彻国防专用软件能力成熟度二级的方法、规范与组织管理的总纲, 也是基于CMM项目管理系统的基础和依据。

国防专用软件能力成熟度模型将组织的软件能力成熟度分为5个等级, 分别是:1级称为初始级, 2级称为可重复级, 3级称为已定义级, 4级称为定量管理级, 5级称为优化级。如图2所示:

具体介绍如下:

初始级 (1级) :从事软件项目工作人是的能力决定软件项目性能;解决问题的模式是“救火”式的;软件项目性能不可预测;软件组织面临的主要问题是管理问题, 而非技术问题;软件管理完全不透明, 仅通过某些杂乱无章的过程生产软件。初始级无关键过程域。

可重复级 (2级) :建立了有效的软件项目管理;软件项目管理过程被文档化并得到遵循;有一个组织方针来指导项目建立管理过程;能重复以前项目的成功实践;项目管理到位。可重复级的关键过程域为需求管理、软件项目策划、软件项目跟踪与监督、软件质量保证、软件配置管理、软件子合同管理。

已定义级 (3级) :它建立在软件项目管理的基础之上;为了控制一个过程, 过程就必须是已定义的、已文档化的和已被有关人员理解的;组织已建立了一整套标准的软件过程, 并且组织中的每个人和项目均能照此执行, 已按妥善定义的过程管理, 过程中的角色和职责已被理解;整个软件过程中软件产品的生产是可视的;除了里程碑处外, 在各开发阶段中设置了更多的检查点。已定义级的关键过程域为同行评审、组间协调、软件产品工程、集成软件管理、培训大纲、组织过程定义、组织过程焦点。

已管理级 (4级) :运用统计过程控制的原理, 阐述过程变化的具体原因。产品和过程被定量地管理, 管理决策有客观测量为基础;管理者能在定量边界内预测性能;而且可以进行交互控制。已管理级的关键过程域为软件质量管理与定量过程管理。

优化级 (5级) :识别并消除软件过程性能差的长期原因;持续不断地改进软件过程, 关注连续过程改进, 有纪律的过程改进已成为日常工作方式。优化级的关键过程域为过程更改管理、技术改革管理、缺陷预防。

2 基于CMMI的软件项目管理

2.1 需求管理

软件项目管理的结构体系如图3所示:

软件项目的开发必须以客户的需求为指向, 需求管理目的在于使开发的方向和客户一致, 对客户本身的真实需求有统一的认识和评价。开发方和客户方共同对《产品需求规格说明书》进行评审, 双方对需求达成共识后作出承诺, 同时开发方和需求者共同对《需求文档》进行评审, 设法理解需求的含义, 从各个项目参加者处求得对需求的承诺, 共同评估各项需求对承诺的影响, 并记录对需求的承诺。这一过程完成的文档包括《需求文档》和《需求管理计划》。

主要步骤有如下几步:

(1) 项目经理先在项目内部组织人员进行非正式的需求评审, 以解决明显的错误和分歧。

(2) 邀请同行专家和用户一起评审需求文档, 尽可能地使需求反映客户的真正意愿。

(3) 开发方和客户对需求文档审核后签字, 以产生法律效力。

2.2 软件项目计划

为进行软件工程活动和软件项目管理所制定的合理的计划, 包括预测、项目投入和工期, 确定必要的承诺和执行等, 经过软件项目计划过程后, 我们将得到《项目估计表》、《项目生命周期文档》、《总体项目计划书》、《项目子计划》等文档。软件计划内容包括以下计划, 但每项计划可分立也可合为一体:软件开发计划、SQA计划、风险管理计划、软件测试计划、项目培训计划。

2.3 软件项目跟踪与监督

为了保证软件系统在预期的工作量内按时保质地完成, 需要定期对其主要项目进行跟踪、监测和调整。跟踪的对象通常有规模、工作量和成本、计算机资源、进度、风险和软件工程技术活动等。它的目标是为对照软件计划跟踪实际结果和性能, 当实际结果和性能明显偏离软件计划时, 采取纠正措施并加以管理直至结束, 对软件约定的更改应得到受到影响的组和个人的认可。

2.4 子合同管理

选择合格的软件承包商并有效地对他们进行管理, 包括如何选择软件分包商, 如何建立与分包商的约定, 如何追踪和评审分包商的功效。这期间包括对软件子合同的管理, 以及包括对合同的构成成分的管理, 如子合同中含有的软件硬件及其他系统成分的管理。

2.5 软件质量保证

过程和产品质量保证过程域引入的动机是为了有一个相对独立于项目的成员, 能够以第三方角色保证项目组成员遵守事先的约定, 遵守作业流程以及对产品制定的标准和规则。使工作人员和管理者能客观了解过程和相关的工作产品, 确保所策划的过程得以实施, 从而支持交付高质量的产品和服务。

2.6 配置管理

配置管理的目的是运用配置标识、配置控制、配置状态统计和配置审计, 建立和维护工作产品的完整性。最后得到的文档包括《识别的配置项》、《配置管理系统》、《基线》、《变更请求》、《配置项的最新履历》、《配置项的状态》以及《配置审核结果报告》等文档。

3 达到CMMI的基础和策略

要使管理过程高效, 首先就要抓好项目管理, 关键也就是抓好几个关键过程域。国防工业企业的软件开发要达到可重复级必须从思想、组织和技术三方面做好准备。

思想上的准备, 首先是企业领导的高度重视, 并及时且有效地控制。企业领导必须彻底认识到国防专用CMMI的重要性, 以及其给企业软件开发能力带来的深远影响, 从内心上、根本上保证基于CMMI的软件项目管理工作的进行。不但要求领导, 也要求企业内所有人员提高认识, 在企业内进行动员、学习和培训是必要的, 这对全员统一思想, 完成思想转换是有极大促进作用的。

企业项目人员构成合理, 有具有相当权威的高层领导参与, 有专职的部门设立, 有专职的项目经理负责, 这些是在组织机构和人力资源上为项目实施提供了保证。实施CMMI, 要建立软件工程过程组、系统测试组、软件质量保证组、软件配置管理组与软件配置控制委员会。同时还需要优秀的实施顾问参与项目, 提供优秀的实施计划方案。

技术上的准备, 首先是对CMMI的研究, 所有的开发人员尤其是高层的领导和开发人员必须对CMMI非常熟悉, 不是只知道个大概或者基本概念, 而要求领悟其内涵和精髓, 以便在实际工作中能自发地尊重规范来进行软件项目的管理工作。

4 结束语

软件开发过程是一个复杂多变的过程, 多年来出现了大量的软件工程技术, 然而软件工程从来没有像其他传统工程那样易于控制。实践告诉我们软件过程改进是一个长期的、没有尽头的过程。CMMI为我们带来了提高过程能力的途径, 不过不同的组织机构的情况各不相同, 其实施CMMI的方法也会不一样。

参考文献

[1]车玫.大力发展自主软件——军工制造业数字化的坚实基础[J].航天制造技术, 2004 (1) .

[2]付庆宏, 琚章锋, 甘宁.军用软件研制过程的管理与控制[J].火力与指挥控制, 2005 (4) .

[3]单银根, 王安, 黎连业.软件能力成熟度模型 (CMM) 与软件开发技术[M].北京:航空航天大学出版社, 2003 (5) .

[4]朱卫平.基于CMMI的国内中小型软件企业软件过程改进研究[D].中南大学硕士学位论文, 2006.

[5]李晓堂.应用CMMI模型改进软件项目开发流程[J].深圳信息职业技术学院学报, 2006 (2) .

软件测试管理方法 篇10

1 软件工程管理

软件工程管理的内容及过程都有着特殊性, 为了确保软件工程管理能够取得成功, 作为工作人员必须要对自身的工作范围进行清楚的了解, 其中包括:目标、工程量、资源、进度、以及风险等。对软件工程项目的管理应当在开发软件之前就着手, 并且要将软件工程管理贯穿整个软件开发过程之中, 只有到软件工程的一切活动结束后, 软件工程管理才可停止。PMI对很多重要理念都进行了定义, 其中最重要的就是制定了一个准则, 该准则将软件工程管理定义成流程管理, 它对整个软件管理过程进行了划分, 分为五个阶段, 其阶段顺序为:启动、计划、执行、控制、结束[1]。这种划分在任何软件工程项目中都适用任何软件项目都由计划开始直到结束, 一个项目规程要由几个步骤来完成, 每个步骤也都是项目中的必要阶段, 项目从启动到结束称作项目的生命周期。在项目的五个阶段中, 计划阶段是项目是否成功的基础, 项目的最终目标是满足客户的需求, 而能否满足客户的需求取决于最初的计划, 只有计划符合了需求, 才能使客户满意。整个项目的过程结束后, 还要做好收尾工作, 一个项目结束后, 要对项目进行总结, 总结整个项目开发过程中的得失, 总结开发过程中获取的经验, 将总结内容编写成文档, 做好资料保管工作[2]。

2 软件工程管理中存在的问题

软件工程是一项专业性强、难度大的学科, 目前软件工程管理还处于发展期, 但其放在何处都会成为一个性质有效的管理。我国部分小型软件企业要想在激烈的市场竞争中获取成功就必须要进行软件工程管理。不过对软件工程进行管理并不是一件容易的事, 在整个管理过程中需要面临以下问题。

缺乏系统的培训。现在我国的一些软件公司的实际情况都是任命专业能力过硬的人员为项目经理, 而这些专业知识过硬的技术人员通常没有过硬的软件工程管理功底, 而企业没有系统的培训, 导致了项目经理在软件开发过程中无法对整个过程中进行系统的管理。

缺乏计划意识。项目经理对软件开发中计划的作用没有一个正确的认识, 导致了开发项目没有一个合理的可行性计划, 这样在软件开发过程中, 因为人员因素或外界因素经常会导致计划好的事情被拖延, 从而造成进度受到拖延[3]。

缺乏管理意识。因为在软件开发中, 项目经理经常投入到技术工作之中, 从而忽略了对软件工程的整体管理。这样经常会造成项目开发过程中, 每个工作人员的任务得不到适当的安排, 造成计划不周, 资源浪费等。项目经理没有将任务合理地分配到工作人员手中, 造成许多任务都需要自己埋头苦干, 没有精力对整个项目进行管理。

风险管理中的问题。部分项目经理在管理中缺乏风险意识, 很少对项目中存在的风险进行合理分析, 制定的风险管理也比较随意, 没有真正起到风险防范的作用。

软件工程复杂化。近年来软件项目规模不断增大, 参与同一软件项目的人数也在急剧增加, 同时软件工程管理的困难也变得更大, 在软件工程管理中需要解决的问题也在增加, 这些都增加了软件工程管理的难度[4]。

3 软件工程的管理方法

某软件公司针对软件工程管理制定了以下管理方法, 经过实践, 取得了不错的效果, 下面我们就几种管理方法加以介绍。

3.1 构建软件工程管理体系

构建合理的软件工程管理体系主要包括以下内容:第一, 构建人才体系。在软件工程管理中, 人才对管理有着重要的作用, 人才是做好软件工程管理的前提。第二, 为了提高工作人员工作中的积极性, 确保项目中所有目标能够得到落实, 应当加强人力资源管理。第三, 在人才的管理中切记要以平等的态度进行管理, 而不是控制[5]。

3.2 加强风险管理和进度管理

对于软件项目管理中的风险管理和进度管理, 我们也应当分为两个方面来进行探讨。第一, 构建风险管理体制, 只有这样才能及时发现软件工程管理中存在的风险, 并对存在的风险进行及时处理。第二, 提高项目中风险管理人员的风险意识, 确保风险管理人员能够对风险有一清楚的认识, 并且能够对风险进行合理的分析, 针对风险提出有效的风险防范制度。在风险管理中风险管理人员应当将风险报告提交给项目经理, 对项目中存在的风险进行有效的防范, 阻止风险出现, 确保企业的顺利发展[6]。

3.3 加强对项目团队的管理

首先, 应当增加工作人员之间的联系与沟通, 使整个团队中的人员都具有沟通意识和团队合作精神。其次, 对各个工作人员的工作内容进行明确分工, 合理地将责任分配到每个工作人员, 保证工作开展后一切都能顺利地进行。最后, 调动项目中工作人员的积极性和注重性, 使团队中的工作人员都能够完全投入到工作之中, 提升团队工作能力, 改善工作人员的工作态度, 做好软件工程管理工作。

3.4 对软件工程进行监督

软件工程监督是软件工程管理中的重要方式, 工程监督指的是对项目所自制定的目标进行实时监测, 软件工程监督要贯穿整个项目, 其目的在于对软件开发的流程进行规范。软件工程监督, 可以使开发过程中的成本、进度、质量实现透明化。在对软件监督过程中软件需要完成以下任务。

由项目负责人对项目进行监督, 在监督过程中, 要对监督数据进行总结, 并对数据进行合理分析, 及时发现问题并解决问题。

将CMM标准应用于软件工程管理之中, CMM标准的引用可以提升软件开发效率, 降低软件开发中的成本以及风险, 缩短开发时间, 提高软件质量, 总之将CMM标准运用到软件工程管理之中, 能够确保用户得到理想的软件产品。

4 结语

综上所述, 软件工程管理是一项复杂的工作, 而在软件开发中又离不开软件工程管理。因此在日后的工作中, 我们需要加强对软件工程管理人才的培养, 使其能够在软件工程管理中发挥应有的作用, 虽然我国的软件工程管理水平同发达国家相比还存在着一定的差距, 但是相信通过工作人员的不断努力, 在不久的将来, 我国软件工程管理水平一定会站在世界的领先行列。

摘要：科技的发展促进了各国之间信息的交流, 各国之间的信息交流也增加了对科技发展的要求, 我们生活在一个信息时代, 信息交流已成为了日常生产和生活的必要活动。软件工程已经成为了现在社会发展的一个重要目标, 同时也是社会进步的标志, 现在人们的生活中已经离不开计算机, 社会的方方面面更是离不开计算机软件的应用。随着计算机技术的普及, 使得计算机已成为了文化交流的重要桥梁, 软件工程管理对计算机的发展和信息交流有着重要作用, 该文针对软件工程管理的有效方法进行了介绍, 希望文中内容可以对相关工作人员能够起到一定的帮助。

关键词：软件工程,管理方法,创新策略

参考文献

[1]任红建.基于过程的软件工程进度估算方法的研究[J].中国科技信息, 2012, 10 (1) :138-140.

[2]刘克青, 廖建新, 张俊光.软件工程策划中的工作量估算方法探讨[J].计算机工程与应用, 2013, 10 (27) :90-92.

[3]邓治文.基于需求分析的软件质量目标策划方法[J].微计算机信息, 2010, 6 (1) :187-188.

[4]马丹.浅析计算机软件工程的管理和维护[J].中国科技信息, 2013, 8 (13) :17-19.

[5]解晓丽.关于对计算机软件工程的管理和维护探讨[J].中国科技信息, 2013, 2 (13) :21-22.

计算机软件的测试方法与分析 篇11

【关键词】计算机软件；测试；方法与分析

面对激烈的市场竞争，很多软件开发商为了能占领一席之地，对软件进行各种升级更新、测试与维护，最终的目的是把自己的软禁推向市场，从而更好的为社会服务，也获取最大的经济效益。没有经过测试的软件，很大程度上面临质量不佳、运行风险，对企业造成负面影响，影响企业地位和信誉。特别是一些关键的核心软件，如医疗卫生系统软件、订票系统软件、银行结算软件等，如果没有进行严格的事前检测，造成的后果将不堪设想，所以，计算机软件的测试则是一个很重要的环节，必须引起重视，对软件进行测试评估，保证软件的运行质量。

1.计算机软件测试的方法分析

软件测试作为计算机工程的一个重要环节，是提高软件质量的保障，软件的测试需要很强的逻辑性。关于计算机软件测试的方法分类，目前主要有四种：即静态测试、动态测试、黑盒测试、白盒测试。

1.1静态测试

所谓静态测试指的是不执行计算机程序代码来寻找程序代码中的问题与错误，这一过程需要人工手动进行，或者借助其他工具完成。

1.2动态测试

所谓动态测试指的是在计算机的实际运行中，测试软件的程序，对程序的真实情况、发生动态进行分析和处理的过程。

1.3黑盒测试

黑盒测试指的是根据软件产品的功能，通过检测的方式对每一部分的功能进行检测，从而检测软件是否正常使用，黑盒测试的理念是把测试系统看成一个黑盒，通过外界输入的方式，在输出检测结果，从而得出结论的过程。黑盒测试的主要优点在于：简单容易操作，不需要很复杂的内部代码，测试与计算机软件的内部没有很大关系，从用户的角度出发，很容易解决问题的发生，功能的实现等。而且黑盒测试在自动化测试中也很方便。黑盒测试起着重要的不可替代的作用。随着软件开发平台及软件设计思想的进步和发展， 对黑盒测试提出了更明确的要求。人们发现， 必须遵循一定的测试理论， 依赖优秀的测试工具， 才能进行科学、完善的测试。

1.4白盒测试

白盒测试也被称作结构测试或者逻辑测试， 可以查阅被测代码内容的测试工作。但是需要知道程序的内部设计结构、具体代码， 并根据基础程序来设计测试。白盒测试的优势在于测试用例在代码上什么地方被忽略。帮助软件测试人员增大代码覆盖率， 提高代码质量， 发现代码隐藏问题。

2.计算机软件测试的手段分析

2.1 web网站测试手段

随着网络系统的普及，基于internet的浏览器、服务器结构的大型应用软件越来越多，一套软件应用系统是否可以承受大量数据，向多个用户同时间访问，并且用户不会感觉反应慢、系统失灵、登陆不上等状况。如果采用模似实际情况，找若干台电脑和同样数目的操作人员在同一时刻进行操作，后拿秒表记录下反应时间，这样的手工作坊式的测试方法不切实际，还无法捕捉程序内部放入变化情况，所以就需要压力测试工具。测试的基本方略是自动负载测试，即通过在一台或几台机上模拟成百或上千的虚似用户，同时执行业务，对应用程序进行系统测试的过程。工具还可以同时记录每一事务处理的时间，中间服务的峰值数据，数据库的状态。主要测试包括交易处理性能指标、资源监控。其中交易处理性能指标包括交易结果，每分钟交易数、交易响应时间， 最小服务的响应时间，平均服务的响应时间， 最大服务的响应时间等。压力测试的过程， 即逐渐增加负载，直到系统瓶颈或不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程，最后由测试工具自动生成测试报告与测试结论。

2.2测试工具选择

目前市场上的性能测试工具种类很多，可简单划分为以下几种：负载压力测试工具、资源监控工具、故障定位工具。负载性能测试工具的原理通常是通过录制，回放脚本，模拟多用户同时间访问被测试系统，制造负载，产生并记录各种性能指标，生成分析结果，从而完成测试的任务。

主流负载测试工具的主要内容是偏写测试脚本，脚本中一般包括用户常用的功能，然后运行脚本， 得出报告。

3.计算机软件测试的过程分析

3.1测试的计划

测试计划就是定义一个测试项目的过程， 确定各测试阶段的目的和策略， 以便能够正确地度量和控制测试。这个过程将输出测试计划文档，明确要完成的测试过程的每一个阶段提供清楚的目标。

3.2测试的项目设计

测试设计是在软件开发设计阶段进行的测试工作，需要被测方提供较规范的软件需求规格说明、 概要设计、详细设计。测试设计是测试过程中最重要的阶段。在这个过程中将定义测试用例， 测试用例的设计对整个测试工作的成败起了决定性的作用。测试项的设计步骤分为以下几步：首先是 测试项的设计分析式样，使用各种技法、矩阵、错误的推测设计测试项。其中具体的技法会在后面做详细介绍。

其次是结果确认的讨论。测试项组合/ 重复的删除。从测试项中删除将没有依存关系的内容组合起来进行测试的项目。，删除根据多种测试技法做成的测试项中的重复项目。再次是测试项目的review有没有无效的测试项， 有没有重复的测试项， 测试项是否有遗漏，结果确认方法是否妥当。

3.3测试的准备

测试准备阶段是在测试实施之前，构造测试计划中说明的执行测试所需的要素，这些要素通常包括驱动程序、测试数据集、实际执行测试所需的软件； 同时为每个测试过程选择适当的测试用例； 准备测试环境和测试工具。

3.4测试的实施

按照测试计划， 使用测试用例对待测项目进行逐一的、详细的测试。将获得的运行结果与其他结果进行比较、分析和评估， 判断软件是通过了每项测试还是失败， 确定开发过程中将要进行的下一步工序； 同时记录、跟踪和管理软件缺陷。在每个测试执行之后， 对发现的错误都要进行相应的修改。当软件修改以后， 必须运行原有的全部测试用例重新测试， 并验证测试结果， 这样可确保修改后软件的正确性和质量。应定期进行回归测试， 看该错误是否会重新出现。回归测试是确认已测试的问题已不再存在的一项工作， 每进行完一个阶段应检查执行结果与测试计划或测试设计文件中是否存在差异。若存在差异就应针对差异进行适度的调整， 可能是修改测试设计文件的内容及测试计划的进度、安排等各种情况。

3.5测试的报告

将测试执行阶段得到的测试结果进行测试分析和汇总，测试观点是否有遗漏，结果确认方法是否妥当，依次评定测试用例、测试项、软件总体质量等级。如果必要， 还应该组织专家评议， 最终得到测试报告。测试分析报告的结构可以参考计算机软件产品开发文件编制指南。

3.6测试包整理

开发结束后， 整理测试包以便于下期开发时用来进行降级测试。软件测试是通过使用各种方法， 黑盒或白盒方法发现错误，分析错误，找到错误的分布特征和规律，从而帮助项目管理人员、开发人员发现当前所采用的软件开发过程中缺陷， 以便改进。同时也能够通过设计有针对性的检测方法，改善软件测试的有效性。完整的软件测试不仅可以给软件进行一个正确的评价，而且是提高软件重要的方法之一。

【参考文献】

[1]马瑞芳，王会燃.计算机软件测试方法的研究[J].小型微型计算机系统，2003，（12）.

[2]刘竹林.我国计算机软件测试现状分析[J].华南金融电脑，2004，（09）.

[3]吕雄津.浅谈计算机软件测试技术与保护技术[J].计算机光盘软件与应用，2012，（09）.

[4]刘皓，李长命.软件测试简述与展望[J].江苏现代计量，2008，（01）.

[5]陈琳，陈玮.软件测试中设计技法与测试过程的研究[J].现代电子技术，2006，（08）.

中小型软件项目进度管理方法研究 篇12

一、基于工作量的软件项目进度估计?

基于工作量的中小型软件项目进度估计, 是在软件工作分解结构分解得足够细的情况下, 先对软件项目的规模进行估计, 根据规模估计出工作量, 再根据工作量估计项目的进度。对于规模和工作量的估计已经有了很多的探讨, 下面研究在工作量已知的情况下, 如何基于工作量估计中小型软件项目的进度。

一般情况, 中小型软件项目的进度估算主要分两种情况, 一种是先确定资源, 由项目根据给项目配备的人员情况以及项目的任务情况, 确定一个最后的结束时间;另一种是先确定最终结束日期后估算, 根据估算情况配备人员和资源, 用工作量除以时间得出人员要求。下面将这两种情况结合在一起进行进度估计方法的研究, 具体步骤如下:

步骤1:根据合同或市场期望的时间确定项目的总体时间要求, 即项目的完成日期A;在大多数情况下, 项目的最终完成日期或交付日期是由市场、顾客或根据组织的要求提前确定的。

步骤2:根据工作量估计值和项目组人员情况估计项目开发所需天数, 计算方法为:每阶段的工作日= (本阶段工作量估计值/本阶段参与人员) *修正值, 修正值由项目经理根据本项目具体情况确定, 修正值范围为0.8~1.5 (修正值也要考虑到有些任务不能同时由很多人来一起干的情况, 如需求分析阶段) 。并由此估计项目的预计完成日期B, 估计时应注意以下换算关系:

1人年=12人月1工作年=12工作月

1人月=22人天1工作月=22工作日

1人天=8人时1工作日=8小时。

在进行这一步骤时, 最好能通过收集历史数据, 并进行分析统计来确定组织每人月的平均有效工作时间, 在分析过程中应考虑到组织的休假制度等各种情况。

步骤3:比较A、B, 若B>A, 项目经理应采取以下措施:a) 调整项目人员安排;或b) 与公司高管协调资源安排, 直至最终估计结果。

步骤4:根据所选择的生命周期模型和项目各阶段工作量的分配百分比, 确定项目的里程碑, 规定在里程碑处须完成的产品或达到的目标。

步骤5:根据产品的功能WBS, 分析各阶段任务的关键依赖关系, 识别出影响项目进度的关键活动。确定哪些模块可以并行独立开发, 哪些模块必须串行开发, 定义出各功能模块的开发顺序, 列出模块的开发顺序表, 尤其要标明模块之间的依赖关系。

步骤6:确定项目进度:根据合同或市场期望的时间要求、项目生命周期、各阶段工作量百分比、活动WBS及所识别的关键路径和依赖关系, 确定项目的各项任务和时间, 同时记录进度估计的假设, 并最终形成项目的进度甘特图。

步骤7:协调计划和资源情况 (SEI, 2008) :进度计划制定出来后, 项目经理组织协调并确认资源的可用性问题, 如果估计的资源和可接受的资源之间有差异, 则协调解决;如解决不了, 则对计划进行修改, 使资源和计划取得一致, 如可通过降低技术性能要求、寻找方式提高生产率、外购等方式来进行调整。具体包括下步骤:

协调人力资源:与估计中所需用到的人。力资源的相关人员及其负责人进行沟通, 明确所有项目成员的到位日期和可投入工作量的百分比;计算除去各项必要的时间耗费外可用的工作量资源;将各项可用的人力资源与估计的情况进行比较, 如有任何差异, 则必须协调解决, 如不能解决, 则必须与组织高级管理者或与客户进行协商, 以使工作量与进度及需求相匹配。

协调其他资源:针对组织内共用的各项。软硬件资源进行沟通, 检查所需资源的使用日期和时间段是否有问题;针对需要其它相关方提供的资源, 与提供方协商确定;检查所需资源使用的具体日期和时间段是否有问题, 如有问题则协调解决。

步骤8:召集项目组成员、高级管理者、客户及其他共利人员对各项估计情况进行评审, 以获得对各项估计的承诺, 计划经评审、批准通过后开始实施。

二、中小型软件项目进度层级及细化

对于进度安排一般分两级进行, 首先确定整体进度和主要里程碑, 然后确定详细进度。刚开始因为项目所掌握的信息比较有限, 所以会先制定一个概要的整体的进度计划, 但在项目进行过程中, 每个阶段开始的时候, 都应该对该阶段的计划进行细化, 形成一个详细的阶段进度计划, 阶段计划一般要求任务粒度细化到一周。在每周开始的时候, 还要求制定详细的周计划。在做阶段计划的时候, 除细化进度外, 还应细化工作量, 细化到两周左右;并用工作量代表费用, 用挣值法来进行成本和进度监控。

另外估计的时机也具有可变性, 例如:根据项目的实际情况, 可以在需求分析完成后再估计项目整体进度, 而在需求分析完成前只做需求分析阶段的进度计划。

下面以某公司正在开发的一个“YNY项目”为例进行介绍。在这个项目中有“X1模块”这样一个模块, 在项目刚开始的时候对这个模块的设计阶段只制定了一个概要的计划时间点, 如表1所示;而等设计阶段开始时, 便对这个模块制定了一个详细的阶段计划, 如表2所示。在制定计划的时候, 对于最后的结束日期一般会设定为一个时间点, 但必要时也可以将其设定为一个区间。

在进度计划制定出来之后, 在每个大的里程碑结束的时候, 还必须根据计划的执行情况, 重新进行进度计划的估计, 不断的重复, 直到项目结束, 所以也有人说, 当项目结束了, 最终的进度计划也就出来了。

三、中小型软件项目进度监控

(一) 中小型软件项目偏差的处理

谈到项目的进度监控及管理, 同样需要思考这样一个问题, 提前完工 (进度提前) 的项目就是好项目吗?答案是不一定, 项目进度晚了固然不好, 但提前完工, 也有可能会有问题, 可能有几个原因:一是制定计划时估计不准确。本来应该5月份完工的项目, 估计成10月份完工, 结果项目是7月份完工, 虽然比计划有所提前, 但仍然不是一个好项目。二是质量没达到要求或费用超支。三是即使质量达到了要求, 费用也没超支, 如果一个项目的一部分提前完工了, 也有可能提前过早地占用了资源, 而导致项目的总体成本提高, 比如说一笔资金, 本来准备6月份投入, 结果2月份用了, 就有可能会提前占用资金。四是当然也有可能是因技术改进, 导致生产率提高而提前完工, 这时就应总结经验, 改进组织的过程。

因此对于进度偏差情况, 要根据具体情况区别对待。那么什么是偏差呢?所谓偏差就是实际进度与计划进度的差异, 通常情况偏差分为两种, 一种是刚才所提到的进度提前的情况, 称之为有利偏差;还有一种是进度滞后的情况, 又称之为不利偏差。不管是有利偏差还是不利偏差, 当偏差发生后, 应该采取如下几个处理步骤。

原因分析:进度的提前是因为管理效率高, 还是因为采取了不正当手段, 或标准定的不合理造成的?

系统分析:有没有因为偏差而对其他目标产生影响, 如:有没有因为进度提前, 而影响到项目的质量和费用等。

采取对策:如进度的提前是正当的, 则应该对项目人员进行激励;如不正当, 则进行处理。进行总结评估。对偏差的产生原因, 及经验教训进行总结, 并将总结结果纳入到组织的体系流程中, 以改进提高组织的项目管理水平。

偏差处理是一个经常性的活动, 通过这些活动就是要使项目始终处在一个状态, 就是“受控状态”即一切尽在掌握之中, 避免“失控状态”的出现。

在项目完成后, 根据最终实际进度与最初计划进度之间的偏差, 判断估计是否准确及项目完成计划的能力。若偏差较大, 应采取措施对项目所采用的估计方法进行改进, 为以后项目的估计提供帮助。

(二) 帕金森定律在监控中的应用

帕金森有一条定律:“工作会延展到填满所有的时间”。因此, 在分配任务的时候, 必须要有期限, 没有期限就永远完成不了。定下期限, 可以给项目人员施加压力, 尽快把工作完成, 定期限是在实践中最有效的方法之一。同时, 也必须注意到在安排工作的时候, 人具有很大的伸缩性。人们具有以一定速度工作以便在给定时间内完成工作的能力 (人力的伸缩性) , 如假定一个项目的工作量估计是200人月, 项目按时完成, 花费200人月, 这个估计是好的, 但不一定是最好的。我们没有理由相信他们不能在180人月里完成, 因为工作被“扩展”了。人们有“扩展工作以填充充裕的时间”的心里。如果估计为200人月, 有可能得220人月才能完成, 但100人月是肯定完成不了的。所以说一个项目即使正好按计划完成, 也得分析一下, 看人员利用率如何?有时候往往容易出现这样的情况, 时间估计过多, 比如说2个月能完成的项目, 估计了3个月, 结果正好按时完成了;也有可能是3个半月的项目, 你估计了3个月, 也正好3个月完成了, 这几种不同的情况, 人员的疲劳程度是不一样的, 所以组织在进行项目监督与控制的时候, 必须考虑到项目人员的这种疲劳程度及“利用率” (Pankaj, 2003) 。这同时也要求组织在进行项目策划的时候进行合理的估计, 虽然合理的范围不是很大, 但也会给估计模型以充分的余地;估计总能实现不是因为其非常正确, 而是因为其合理。

(三) 进度压缩

在进度执行过程中, 经常会因客户的需要, 不得不进行项目进度的压缩, 那么应该如何来压缩项目的进度呢, 压缩过程中应该注意一些什么原则呢?在进行进度压缩的时候, 一般有两种方法:应急法和平行作业法 (韩用明, 2003) , 应急法是权衡成本和进度间的得失关系, 以决定如何用最小的增量成本达到最大量的时间压缩, 常导致成本增加, 平行作业法是平行的做活动, 如在设计完成前就进行编码, 常导致返工和增加风险。但需要注意的是, 当进度被压缩到“正常”范围之外, 工作量就会急速增加, 费用也会迅速上涨。软件项目存在一个可能的最短进度, 这个最短进度是不能突破的。Charles Symons提出的进度压缩费用方法:进度压缩因子=期望进度/估算进度, 压缩进度的工作量=估算工作量/进度压缩因子。例如:项目的初始估算进度是12个月, 初始估算工作量是78人月, 如果期望压缩到10月, 则进度压缩因子=10/12=0.83, 压缩后的工作量=78/0.83=94 (人月) 。也就是说进度缩短17%, 增加21%的工作量。很多的研究表明:进度压缩因子不应该小于0.75, 即进度压缩不应该超过25% (韩万江, 2005) 。

四、结语

总之, 本文所研究的方法是一种比较系统的专门针对中小型软件项目进度管理的体系模型, 能够有效的解决中小型软件项目进度管理所面临的困境, 并首次将人文因素 (人员的疲劳程度) 与软件项目的监控进行了结合探讨。该方法体系具有通用性, 适用于绝大多数中小型软件企业。而对于大型复杂的软件项目, 则必须结合关键路径法一起使用, 仅用本文所研究的方法体系难以实现有效的策划和监控。下一步的研究重点是在大的体系模型确定的基础上, 对项目的偏差设定, 进度压缩因子的具体模型等因素的具体设定进行进一步的建模和研究。

摘要：为提高项目成功率, 研究了一种系统的软件项目进度管理方法.该方法结合实际项目的案例, 考虑到中小型软件项目的特点, 通过获得项目的工作量及各阶段工作量分布, 进行分解得到项目的进度;在进度分解过程中, 充分考虑到项目资源的可靠性和可用性问题;同时, 也对进度计划的细化和监控进行了研究.

关键词：中小型软件项目,进度估计,监控

参考文献

[1]张俊光.软件项目管理的若干关键问题研究[D].北京邮电大学, 2007, 7.

[2] (印) Pankaj Jalote.软件项目管理实践[M].清华大学出版社, 2003.