全过程软件测试（精选12篇）
全过程软件测试 篇1
1 软件的缺陷及测试
实践证明,在软件开发过程中,软件缺陷的生长是呈几何级的。一个问题定义阶段的缺陷,将在需求分析阶段、结构设计阶段、代码创建阶段产生更多的缺陷,如图1所示。
因此,从问题定义开始,到需求分析、结构设计,一直到代码创建,每个阶段到下一个阶段之间都应该设置一个“质量门”,确保能够准确无误地进入下一个阶段[1]。
软件质量保证是建立一套系统的方法,通过对软件的活动进行评审来验证软件是合乎标准的[3]。
软件测试是软件质量保证最重要的方法,按其是否需要运行程序可划分为静态和动态测试;按其是否关注程序的内在结构可划分为白盒和黑盒测试;按测试不同阶段可分为单元、集成和系统测试。不同的测试手段会发现不同的问题,因此软件测试应该结合多种测试方法,较大限度覆盖代码行和控制条件,尽可能发现软件的问题[4]。
2 继电保护软件开发及测试
继电保护软件从功能需求上可以划分为操作系统、基础平台、保护应用、接口、通信、网关等。在对每一个功能块进行设计时需要进一步细分成二级功能块,例如基础平台可以分为模拟量管理、开入量管理、时间管理、内存表管理等;保护应用可以分为过流保护、差动保护、距离保护、过量保护等。再对二级功能块进行划分成三级功能块,例如时间管理功能块可以分为获取当前时间、时间转换、获取GPS时间、获取主任务执行时间等,三级功能块大部分为函数级别的模块[5]。
对继电保护软件进行测试时,要和设计相反的顺序来执行测试。首先对函数级别的模块进行白盒测试,这个阶段的测试非常重要,它是整个测试的基础,问题缺陷在本阶段发现的频率最高,但修改成本最低。单元测试完成后,把通过测试的模块集成为二级功能块,在装置上对二级功能块进行集成测试。最后在装置上进行整个系统的测试。
3 继电保护软件全过程测试
3.1 单元测试
把继电保护软件按照功能实现划分为相对较小的模块,在程序员对其编码完成后,把各个模块集成起来前,必须对单个模块进行测试,称为单元测试。
单元测试分为测试环境搭建、测试用例设计和测试执行3个阶段。
3.1.1 测试环境搭建
在单元测试之前要进行测试环境的搭建,为了模拟继电保护运行所需数据,构建了公共数据平台和控制平台,公共数据平台是模拟装置常用的输入输出数据,包括模拟量、开入、开出、遥控等的设置;控制平台主要是模拟装置运行速度,包括采样指针控制、系统时钟控制、通道接受数据个数控制等。测试用例和测试结果的保存采用文件的方式[5]。整个程序架构如图2所示。
驱动模块:调用所测模块运行的主程序,也就是main函数。
桩模块:也叫做存根模块。用来代替所测模块调用的子模块。
在程序设计中除了构建公共数据平台和控制数据平台外,最主要的就是测试用例的构建以及存储。一个完整的测试用例信息包括输入参数、输出参数、返回值、预期输出参数以及预期返回值,因此一个模块的测试用例信息结构如下:
在驱动模块调用被测模块前,测试用例结构体中的前6项通过测试用例文件的读取来赋值;在驱动模块执行完被测模块后,测试用例结构体中的后2项通过模块实际运行结果来赋值,然后把整个测试信息通过固定格式填写到测试结果文件中,从而完成整个模块的测试。
3.1.2 测试用例设计
测试用例设计应该充分考虑到程序运行的各种情况,注意事项如下:
(1)用例数据分为正常,边界和异常3种。
(2)正常数据要考虑坐标系中的4个象限,要求每个象限和坐标轴上都必须有一个测试用例。
(3)边界测试用例主要指数据的刚刚大于最大值,最大值,刚刚小于最大值,刚刚大于最小值,最小值,刚刚小于最小值。
(4)异常测试用例主要指越上限,越下限的数据,非法数据。
(5)对于使用全局数据,执行需要一定的前置条件的模块,设计测试用例时需要考虑模块执行前后全局数据以及其它条件的变化。
(6)用例设计要求达到路径的全覆盖。
(7)为程序的浮点等于,不等于,与0比较处设计测试用例。
(8)为无符号整形和整形之间的比较处设计测试用例。
(9)为无符号整形数据的翻转设计测试用例;
(10)继电器类模块还要根据动作特性图设计测试用例:
1)动作区域外。
2)动作区域内。
3)靠近动作区域边界内一点。
4)动作区域边界。
5)靠近动作区域边界外一点。
3.1.3 测试用例执行及结果判断
在测试用例的执行过程中如果结果出现错误,就要进行逐步调试找出问题原因,以便给设计人员提供解决方案。
对于继电器的模块,最直观的测试结果就是生成继电器模块的动作特性图。为此采取设计大量测试用例,循环执行测试用例,把测试结果生成图形显示出来。例如,比相圆继电器的动作特性如图3所示。
对于傅里叶算法类的模块,最直观的测试结果就是把模块的幅频特性(反映滤波算法对不同频率信号的衰减程度)、幅相特性(反映滤波算法的幅值滤波精度)和相移稳定性(反映滤波算法的相位滤波精度)用图形表示出来。为此采取设计大量测试用例,循环执行测试用例,把测试结果生成图形显示出来。例如,三通道差分傅氏算法的如下幅频特性如图4所示。
3.2 集成测试
单个软件模块测试正确后,按照功能需求将模块组合起来进行测试叫集成测试,主要测试模块间数据传递正确性和系统组成后的逻辑结构的正确性。
集成测试采用黑盒与白盒相结合的方法,即根据集成设计逻辑图进行模块集成的功能测试。集成测试在实际装置上进行测试验证。
例如对变压器保护中的分侧差动保护进行测试,程序的集成设计如图5所示。
分侧差动保护中最主要的两个模块是相差继电器和延时元件,在集成测试阶段,这两个模块的测试是通过的。三折线相差继电器的动作特性图如图6所示。
在设计测试用例时,首先根据动作特性图通过改变差动电流、制动电流、比率制动系数等数据,让三折线相差继电器在不同条件下动作或返回,经延时后,查看差动保护输出是否正确;然后固定继电器模块的输出,改变延时定值,查看差动保护输出是否正确[7]。
3.3 系统测试
集成测试完成后,从用户的角度对保护软件进行黑盒测试,验证每一项具体的功能。系统测试主要包括装置文档测试、功能测试、性能测试、人机接口测试等[8]。
依托现有继电保护测试仪开发了一套自动测试软件,系统结构如图7所示。
测试软件与测试仪客户端通过以太网实现程序间通信,完成控制测试仪软件命令下发和接收测试结果的功能;测试软件与被测保护软件采用基于IEC61850标准的MMS通信协议实现单播通信,完成控制保护软件命令下发和接收动作报告、录波、遥信变位等信息的功能[9]。自动测试软件的控制命令是从测试用例库中自动读取的;自动测试软件还能够把接收的测试结果和动作报告等信息自动生成测试报告[10]。
自动测试软件实现了测试任务自动控制、结果自动判别、自动生成测试报告,在继电保护软件的系统测试工作中,使测试效率得到显著提高,测试更加全面充分,有效排除了人工测试的不确定因素,保证了测试一致性[10]。
4 结语
目前国内软件测试正处于快速发展阶段,许多公司都建立了自己的测试队伍,软件质量在一定程度上得到了保障。另一方面,测试的广度和深度是一个难以把握的难题,不能仅仅以测试覆盖率来评价,需要从不同的测试阶段、不同的测试项目来综合评估,这就是所谓的全过程测试。
依照测试的不同阶段对继电保护软件的全过程测试进行了阐述,全过程测试比传统的继电保护软件测试增加了单元的白盒测试和集成测试。特别是单元白盒测试的开展对继电保护软件运行的稳定可靠性有重要意义,时间加速减速、错误异常数据模拟、异常路径测试等测试项目通过黑盒测试无法模拟,通过白盒测试就可以实现,因此也重点介绍了单元白盒测试的相关技术和方法。集成测试是在单元测试基础上进行的,集成测试的开展使继电保护软件在系统测试更加可靠,同时也在一定程度上减少了系统测试的工作量。
实践证明,在继电保护软件中开展全过程测试能够显著提高保护装置的质量,对于生产厂家和用户都有着积极的意义。
参考文献
[1]ROGER S.P.软件工程[M].梅宏,译.北京:机械工业出版社,2002:12-18.
[1]DIRK HUBERTY.软件质量和软件测试[M].马博,赵云龙,译.北京:清华大学出版社,2003:14-20.
[3]朱少民.全程软件测试[M].北京:电子工业出版社.2007:9-18.
[4]RON PATRON.软件测试[M].北京:机械工业出版社,2006:10-20.
[5]张云.继电保护装置开发平台软件系统架构与设计[J].电力系统及其自动化学报,2005,17(4):20-40.
[6]饶丹,张成彬,樊瑞.继电保护装置自动测试体系设计之白盒测试[J].电力系统保护与控制,2012,40(8):131-134,155.
[7]贺家李,宋从矩.电力系统继电保护原理[M].3版.北京:中国电力出版社,1994:6-15.
[8]刘昊昱,胡宝.继电保护产品测试指导[M].2007:5-50.
[9]浮名军,刘昊昱,等.智能变电站继电保护装置自动测试系统研究和应用[J].电力系统保护与控制,2015,43(1):40-44.
[10]朱忠亭,张沛超,汪可友.基于自动测试的继电保护测试软件研究[J].电力系统保护与控制,2004,32(17):31-33.42.
[11]刘巍,赵勇,石光.智能变电站继电保护装置一键式测试方法及系统[J].电力自动化设备,2013,33(2):152-154.
全过程软件测试 篇2
为解决该危机，必须进行软件过程管理与软件过程改进。
本文首先提出了过程思维的这一新理论概念;其次剖析了软件过程改进的框架;最后给出软件过程的评估方法。
【关键词】软件过程管理 软件过程改进 过程思维 CMM
一、产生背景
目前，软件行业正处于从手工作坊到在其它工业生产中普遍使用的工程化的进化之中。
人们通常都会感到“软件危机”的痛苦：软件的推出总是晚于计划，而成本却往往高于预算，但功能却往往没有预先设计的那么多，并且后期对软件产品的维护比较困难。
为了解决这个危机，软件开发领域中已经逐步开始引入软件过程管理与软件过程改进的概念。
软件过程改进是指在软件开发过程中除了应用先进的软件开发技术和软件开发方法外，还有一整套的软件管理和改进技术。
常见的软件过程改进方法有：CMM、ISO9000、ISO/IEC 15504 等，其中CMM又是事实上的软件过程改进的工业标准。
二、过程思维
“为了解决软件问题，重要的第一步就是将整个软件开发任务看作一个可控的，可度量的以及可改进的过程。”，倡导过程思维的先驱Watts Humphrey在他的著作中是这么阐述过程的。
过程思维也是一种自然的思维方式，我们所拥有的知识和经验实际上也是采用和过程相类似的方法保存在大脑中;但过程思维方式和传统思维方式有所不同。
对于一个软件项目组的成员来说，如果每个成员都能采用相同的过程思维方法，将会统一各个成员的工作目标，为实现最终的目标而共同努力。
如果软件的开发没有围绕过程为中心进行，往往会导致软件开发过程的混乱，使得开发人员不得不到处救急，来维护软件。
三、软件过程改进的框架
当有效的软件过程环境建立好了以后，过程环境中的机制有利于我们建立过程文化和过程架构。
软件过程改进的战略应该建立在当前的软件过程改进环境下的一个整体框架之上。
这些整体框架中标识出了软件过程改进中必须包括的关键的领域。
下面我们介绍一种软件过程的改进框架。
该软件过程的改进框架包括以下四个方面的内容：
(一)软件过程架构：支持过程环境需要两种类型的架构。
一为组织及管理方面的架构，包括角色和职责;另一为技术方面的架构，包括技术工具和相关的设备。
(二)软件过程改进规划图：它指定一个将要采用的软件过程模型，并且规划出实现高效的软件过程的步骤。
软件过程改进规划图为我们指明了实现软件过程所要经历的各个阶段及层次以及为了实现这些目标所必经的关键点。
这些过程模型可以是CMM/CMMI或者ISO/IEC 15504等。
(三)软件过程评估方法：它指出对组织当前软件过程，活动以及架构进行评估所采用的方法及技术.通常评估是根据软件过程改进规划图而进行的。
(四)软件过程改进计划：为进行软件过程改进，根据评估中所发现的各种问题，提出相应的改进解决方案。
通过实施软件过程改进计划，可以提高现有的软件过程水平。
构成框架的这四个部分是相互关联的，任何一个软件过程的改进策略都应该包括这几个部分，否则会造成冲突。
通常是先根据软件过程改进规划图对已有的架构进行评估，然后制定软件过程改进计划，再进行改进，从而达到改进规划图中的软件过程成熟度的级别。
四、基于CMM的软件过程改进
在软件过程改进中，关键要做好软件过程改进规划图的分析工作，并在此基础上进行软件过程评估分析。
下面结合CMM(Capability Maturity Model for Software---软件能力成熟度模型)综合分析软件过程改进。
(一)软件过程改进规划图
软件过程改进规划图会划分出过程改进中不同的阶段，并告诉我们在每一个阶段过程应该具备的特点和属性。
软件过程改进规划图中应该先定义好目标，然后通过过程改进活动提高整个组织的能力成熟度，并且达到最终的目标。
目前最为著名的过程改进规化图是由美国卡内基――梅隆大学软件工程研究所(SEI)提出的能力成熟度模型(CMM)。
CMM主要用于软件开发过程和软件开发能力的评估和改进，其目的是让从事软件开发的公司和人员从被动地去解决所碰到的难题转变为以成熟的、规范化的方式来解决问题，从而提高软件企业生产软件的能力和水平。
(二)软件过程评估
软件过程评估是对一个组织的软件过程进行评估与检查。
软件过程评估可以为我们提供关于当前组织内部所采用的软件过程状态的基本情况描述，而它正是我们进行软件过程改进的基础。
软件分析业中经常使用CMM进行过程评估与改进。
CMM是一个框架，是软件组织提高过程能力的一种途径。
CMM在设计时就以考虑到各种使用问题，所以评估组可以将CMM作为他们对组织内已存在过程进行评估的基础，从而确定出过程的强项和弱点(与CMM中过程定义有关的内容)。
这种评估方法通常分被描述为基于CMM的评估。
五、结束语
要克服软件生产中的这些不如人意的地方，我们就必须采用系统的改进方法。
对一个软件而言，要降低成本，提高效率，提高软件的质量，一个规范化的，系统的软件过程和质量改进方法是非常重要的。
总之，要有效的进行软件的开发，必须进行软件过程的改进，就必须要有效的过程环境，为了使过程环境更加有效，我们需要以下角色和机制的支持：明确的过程职责;关于过程的培训;对过程的度量;对过程执行情况的监控;来自于过程使用者的反馈;来自于外部环境的反馈;过程的强制和检测。
这样才能进行有效的过程改进，从而最终实现我们的目标以及提高软件的质量。
参考文献：
[1]吴天荣，智明.CMM在软件过程中的一些思考[J].福建电脑，，(5).
[2]刘莉，傅英亮，陶强.基本质量的软件过程研究[J].计算机工程与设计，2007，(5).
[3]陈新炜.软件外包服务中的CMM应用[J].商场现代化，2007，(1).
浅谈软件过程的改进 篇3
关键词：软件工程；SEI能力成熟模型
中图分类号：TP311文献标识码：A文章编号：1009-3044(2007)12-21705-01
Discuss the Improvement of the Software Course Simply
WANG Wen-li
(Guangdong Lingnan Institute of Technology,Guangzhou 510663,China)
Abstract:Improvement of soft project in a problem land that is explored constantly soft project researcher in whole world. First of description of this text are organized unripely and a ripe difference while organizing, key definition and describe SEI ability ripe 5 ripe grade of model, propose one common system improvement model to develop course.
Key words:Soft project;Ripe model of SEI ability
1 引言
信息系統生命期(SDLC)由活动、产品和资源组成。活动是在一个SDLC中进行的动作，并且可以是高层分析至程序的编译或者测试之类的任何工作。产品是在SDLC期间产生的文档和程序。资源由人员、时间、金钱和设备等组成。在一个SDLC期间要使用它们，SDLC在某些文献以及讨论开发的研究中也看成是一个软件的过程。
全世界的软件工程研究人员都致力于改进软件过程。SEI（Software Engineering Institute）的能力成熟模型是一种软件过程改进的途径。本文基于这一框架来讨论软件过程的改进。在世界范围内有许多其他实践着的软件过程改进。本文选择这一途径进行讨论，是因为大量的出版物上有有关的文章、讨论及批评，并且在美国和许多其他地区普遍接受了它。在1986年，CMU软件工程研究所（SEI）在Mitre公司的帮助下，开始发展一种有助于开发人员改进他们的开发过程的系统开发过程成熟度框架。最初称为软件过程成熟度模型。
2 不成熟和成熟的系统开发组织
一个组织希望建立起改进信息系统开发过程的实用的目标时，首先必须理解不成熟系统开发组织和成熟的系统开发组织之间的差异。在一个不成熟的系统开发组织中，通常开发人员即兴提出系统开发过程。即使详细说明了一个特定的开发过程，也很少会坚持或强化这一开发过程。
描述不成熟系统开发组织的最好词语是“反应”。通常管理人员关注解决危机和“救火”上。经常性地超支，因为从来没有真正地估计过进度和预算。当人为的期限迫近时，软件产品功能、性能和质量往往受损。
最后，一个不成熟系统开发组织缺乏有目的的办法来评估软件产品质量、或解决发生的产品问题或过程问题。为保持或接近进度，经常减少取消试图提高软件产品质量的活动，例如用户介入，设计评审和测试。
成熟的系统开发组织可能在全机构范围内管理系统的开发和维护。管理人员可以准确地把系统开发过程传达给开发人员，开发人员根据计划的过程实施相应的活动。规定的开发过程是可用的，并和进行工作的实际途径相一致。通过受控的试验性测试和效益分析，确定必须改进过程时，就更新规定的开发过程。在项目范围内和贯通组织范围中都理解开发人员的作用和责任。
成熟系统开发组织的管理人员不断地监视系统产品的质量个制造产品的过程。坚持一个目标明确的、定量的方法来评估系统产品质量和分析产品的问题和过程的问题。基于历史上的行为制定进度和预算，因此是现实的，通常可以达到。
最后，一个成熟的系统开发组织使用一个纪律严明的系统开发过程，因为全体参与人员理解如此做的价值，企业的基础结构设施支持他们达到这一点。
过程改进（例如SEI的CMM）的目的是支持软件开发管理人员，开发人员和业务工作。而不是去责备和羞辱他们。软件过程改进的组织软件开发组织的管理人员之所以失败，常常就是因为害怕承认了软件开发过程真实情况所带来的后果。
3 SEI能力成熟模型的5个成熟阶段
一个系统开发过程是开发人员用来开发和维持信息系统的活动、方法、实践和变换的集合。如果一个软件的开发组织是成熟的，在其组织内具有较好的定义，并一贯地使用于开发过程。通过政策、标准和组织结构体现的系统开发过程是这种成熟性的自然产物。不要将成熟度和多年处于的状态等同。对于现在的讨论中，把成熟度等同于智慧的成熟和在应用知识上的智慧。所以一个软件开发组织成熟就相当于该组织能把通常认可的有关软件开发过程的知识应用于自己的软件开发工作中。
坚持连续地改进过程的思想，CMM为软件为软件组织的演进步伐提供有五个成熟度的框架，如图1所示。当软件组织达到一个成熟度级的框架时，每一个成熟度级为连续的过程改进中转向下一个成熟级打下基础。每一级都假定软件组织已经达到了在CMM指南规定的所有较低级别的要求。图2总结由CMM描述的关键过程区域。
图1 SEI能力成熟模型 图2 在能力成熟模型中的关键过程区域
第1级，初始级软件组织的一般特征是没有开发和维持系统的稳定的环境。这种组织极少能做到使软件开发按一个有序的开发过程进行。结果是发生一系列开发危机，一遇到问题，开发组成员放弃计划好的过程，并回到反复编码和测试。
第2级，可重复级软件组织的一般特征是有食用的政策和过程，并在系统开发中坚持使用。新项目的计划和承诺是基于相似的项目的经验。基本的管理控制是属于每个开发项目的一部分，管理人员跟踪费用、进度和识别问题。
用户需求和开发出来满足要求的工作产品是按基线进行，并控制其完整性，项目遵循标准；然而在第2级的组织中项目之间的过程可能不同。因为可以重复过去的成功经验，所以其项目计划和控制是稳定的。这些组织的过程能力是有规律的。
第3级，定义级按软件组织在相继项目上的稳定性和可重复性，所代表的全组织的标准和一致的系统开发过程来标志。这个过程的编写成文档，包括一个开发人员的过程部件和一个管理过程的部件。由于标准化，组织作为一个整体应当能够进行有效的系统开发时间。
因为在这一级的开发组织有一个很好的定义过程，管理人员对每个项目的技术过程有良好的洞察力。除此以外，在组织的标准化系统开发过程中包括了以下各方面的指南：(1)标准；(2)建立可读性准则；(3)开发输入；(4)完成工作的步骤；(5)工作验证步骤，例如同事评估；(6)开发输出；(7)决定完成准则。
第4级，管理级是建立了系统开发产品和系统开发过程的定量质量目标的几个为特征的组织，对于遍及所有项目的重要的系统开发过程都度量生产率和质量作为自制的度量程序的一部分。
整个组织维护一个过程数据库以收集和分析来自各项目确定过程的数据，这些组织的范围的度量建立了一个定量的基础，用于评估任一项目的过程和产品。每个项目通过在他们行为中减少与组织的可接受数量界限的差别来控制他们的过程和产品。在一个项目过程实施中有实质性的变动和随机变动加以区别，当已知的过程界限超出后，管理可以采取行动来纠正这种情况。第4级允许一个组织在确定的定量范围内对系统开发过程和产品质量具有预测趋势的能力。
第5级，优化级通过整个系统开发组织致力于连续的过程改进为标志。组织有适当的途径识别开发过程弱点和产品弱点，并用零缺陷目标化它们。过程数据库（来自第4级）用来对新技术和系统开发过程的变动进行费用—利益分析。探索最佳系统开发实践的革新在整个组织内部识别并传播。
项目小组分析缺陷以决定原因，对过程进行评估以避免已知类型的错误重现，并传播其他项目的经验。因为系统开发中低效益的主要原因是重复工作，所以减少重复工作可以说是每一级的目标。但是在第5级，它成为一个主要的关注点。
4 一个基本的系统开发过程改进模型
通过遵循这个简单的系统开发过程改进模型——ICASE，一个系统开发组织可以来达到其希望提高CMM的级别的目的。
I=调查，调查组织的系统开发过程的现有状态。在我们可以确定移向下一个级别之前，我们需要知道我们处于哪里。
C=建立，在组织内部建立一种意想。使开发人员和管理人员进入改进系统开发过程的概念中去。
A=行動，在组织中对必须要求的过程改进行动建立一张清单。
S=选择，选择一个计划以达到要求的行动。
E=执行，提交执行计划必须的资源。
最后，当开始并不断在CMM级进行改进时，反复这一过程。
5 小结
本文给出了对软件过程改进的概述。由于许多因素使软件创建的过程需要不断的改进。软件过程改进就是试图这样做的活动。按SEI能力成熟模型——给出软件开发成熟度的五个级别，给出了不成熟和成熟软件开发环境。在这之后，一个一般的系统开发过程改进模型，用ICASE缩写表示。本文简短地讨论ISO 9000过程改进标准作为结束。
如前所述，SEI的CMM不是仅有的系统开发度量模型。还有ISO 9000系列标准，以及可以通过全世界的咨询组织获得几个专利的方案。然而，CMM可能是所有系统开发度量模型当中编写最流行的文档方法。
参考文献：
[1]国刚.UML与Rational Rose 2003软件工程统一建模原理与实践教程[M].电子工业出版社,2006.
[2]符长青.信息系统工程监理[M].机械工业出版社,2006.
[3]周爱民.大道至简——软件工程实践者的思想[M].电子工业出版社,2007.
[4]赵池龙.软件工程实践教程[M].电子工业出版社,2005.
敏捷开发的软件测试过程概述 篇4
1 软件测试的方法
1.1 根据透明度分类
透明度分类是将软件按照不同的透明度归类为黑盒测试和白盒测试。黑盒测试是把软件当作已经放入到一个黑盒子中的一个东西进行测试,测试时无需了解软件的实现过程,是以用户使用的角度进行的测试。白盒测试则是把软件当作放在一个打开的盒子里的东西进行测试,因为盒子是打开的,测试时会对软件的实现与构造一目了然,是深入到软件内部的一种测试。
1.2 根据开发过程分类
1.2.1 单元测试
单元测试属于白盒测试的一种,以盒子打开的形式对软件的代码单元进行测试,在函数式语言中以函数为单元测试。测试的方法是对单元进行编写代码,利用编写的代码进行测试。
1.2.2 集成测试
集成测试属于灰盒测试。灰盒测试是介于黑盒测试与白盒测试之间,测试时同黑盒测试一样,不需要考虑内部实现,也不用像白盒测试那样深入到软件结构中进行测试,只需要测试模块间的接口与配合的关系即可。
1.2.3 系统测试
系统测试属于黑盒测试,不需要了解软件的实现方法,但需要根据软件的规格需求进行测试。软件测试实际是由系统测试演化而来的,系统测试是开发中必要的测试环节,而大多数软件在开发过程中对单元测试和集成测试的要求很少。
1.2.4 验收测试
验收测试是用来验收软件是否能够达到用户的满意度,属于黑盒测试。上文提到的Alpha测试是内部测试,是用户在开发环境或者模拟测试环境下的测试;Beta测试是外部测试,是由软件的一个或多个用户在实际使用环境下进行的测试。两种测试方法均可在验收测试中使用。
1.3 针对性测试
针对性测试是针对软件的某一个或几个质量特性进行测试,比如软件的可靠性、易用性、可维护性等等,是将上文提到的几种测试方法相融合。测试中可能还需要对软件的安全性、性能、内存做针对性测试,测试不仅跨越各个开发阶段,同时也具有白盒和黑盒测试的特质。
1.4 安全性测试
安全性测试主要针对软件的使用安全性,随着互联网的发展,应用软件更容易受到威胁,软件的安全测试就显得尤为重要。可以通过语法、故障注入、模型安全及模糊测试的方法对软件的安全性进行测试。
1.5 性能测试
性能测试是为了验证软件是否能够达到用户提出的性能指标,同时发现存在的瓶颈,起到优化软件的目的。性能测试一般通过自动化的工具完成,如LoadRunner等。,软件性能的好坏往往是决定软件能否赢得用户的重要因素。
1.6 内存测试
内存测试是测试软件运行时的内存是否越界,对于泄漏、缺陷等问题进行检测,能够有效的检测出软件中存在的安全隐患。
2 敏捷开发的定义
敏捷开发(agile development)的概念是在2004年产生的,它是一种以人为本、循序渐进的软件开发方法。敏捷开发中,软件项目被划分为多个子项目,各个子项目的功能通过测试后便可运行。
敏捷开发主要是针对中小企业,这类企业的发展需要团队具有高效工作、满足需求和顺应变化的条件,因此提出了敏捷软件开发的理念。敏捷开发的方法很多,包括Crystal、自适应软件开发(Adaptive Software Develoment,ADS)、特征驱动软件开发及极限编程(Extreme Programming,XP)。
3 敏捷测试人员的定位
敏捷开发近年来受到社会各界的重点关注,原因是它能够应对客户多变的需求并不断进行相应调整开发的一种高效开发模式。敏捷开发中的测试人员也可以叫做QA (质量保证)人员。因此软件从开始设计时就需要与QA人员达成一致,双方的目标都是注重质量,构建软件形成,达到零缺陷的软件开发过程。QA人员需要站在客户的角度去思考,辅助开发人员完成设计和软件的实现,并对软件整体进行掌握,及时提出架构上的问题。QA人员还需要对客户反馈的信息进行统计,以便团队更好的改进问题。此外也需要与开发人员紧密合作,双方形成互补,避免敏捷测试对软件开发无用以及测试不完整的问题出现。
4 敏捷开发的软件测试过程概述
敏捷开发的测试方法不同于传统的测试,在敏捷开发测试中,测试决定整个项目组的去向,明确指出问题所在和改正方向,促使项目组在敏捷测试信息中做出正确的决定,测试人员根据检测出的错误,辅助开发人员进行修正。
4.1 初期测试工作重点
测试人员需要从软件开发初期便进行检测,对开发软件的测试重点是文档的完整性、严密性和功能设计的可测性。测试人员在软件开发初期,需要对软件做好需求分析,对设计做好逻辑分析,将每一环节中的检测结果积极、迅速的反馈给设计和开发人员。
4.2 测试用例设计及评审
敏捷开发的过程中,开发人员可以和客户直接沟通,确定每个功能的优先级。测试人员根据已经通过审核的设计方案编制测试计划,再设计相应的测试用例。测试的主要依据是软件产品设计文档,而这些设计文档也需要项目经理和开发人员一同对其进行审核。
4.3 测试执行
为了方便衡量软件当前的质量和判断测试是否达到出口标准,可以每天对测试结果进行分析,提供问题走势图,将每天新发现的缺陷问题和已被解决的问题的数量制成图表展示。在测试执行的开始阶段,缺陷问题数量会呈上升趋势,到中后期被解决的问题数量会上升,新发现的缺陷数量下降,最终发现的问题数量曲线趋于稳定并向零值趋近。
在发布软件版本之前,测试人员还需要根据发布的版本情况进行说明,对版本的说明应至少包括三方面的内容:已经修复的上个版本中存在的错误、新的功能、此版本还存在哪些问题。
4.4 需求管理
所采用的敏捷开发模式中,客户的需求变更较为频繁,因此对客户的需求进行管理是非常重要的工作。在软件开发过程中,不断的有新变化的需求,这就意味着软件测试的重点和方向需要根据新需求的变化而不断地调整。对于新变化的需求需要进行相应的记录,将每次的变更需求整理记录到文档中,文档始终保持在更新的状态,与客户的需求变化保持一致,方便后期的管理和维护。在敏捷测试中,这项工作由测试人员执行更为合理有效,一方面方便测试人员及时理解需求的变更内容,快速完成用例设计,执行测试;另一方面也能有效的起到质量保证的作用,检查开发人员开发出的产品是否符合变更后的要求。4.5清理Bug
在软件敏捷开发接近尾声时,可以进行一次整体的软件Bug问题大清理,这样做的好处是可以利用测试以外的多方力量,全方位、多角度的发现软件的遗留问题。可以在项目的时间进度安排里预留一个时间段完成这项工作,参与测试的人员需要集中的进行一次检测。需要注意以下几点:(1)参加检测的人员不仅需要包括测试人员,还需要有项目经理和开发人员甚至高层管理人员的加入,便于对发现问题的及时了解,并且集思广益快速解决问题。(2)鼓励各部门之间进行交叉测试,通过不同的思路和视角发现更多的错误。(3)还可以将软件检测进行专题分类,比如安全性检测、用户体验检测、国际化或本地化检测等等。
5 结论
综上所述,为了适应客户对软件产品的要求不断变化而出现了敏捷开发模式,相应地产生了敏捷测试的概念。在敏捷开发的测试过程中,核心关键是快速的响应、完成测试并反馈结果,并与开发同步及时展开测试。。敏捷开发测试不仅是一种高效的检测模式,还能够提高软件质量并且对软件进行预防错误处理。对于敏捷开发测试的发展,社会各界一直持有高度关注,相信通过科学技术的不断探索前进,能够更好的带动敏捷开发测试的应用及发展。
参考文献
[1]徐炳.基于CARD/1的高智能化互通立交设计系统的研究与开发[D].电子科技大学,2013.
[2]宋易欣.基于看板管理方法的敏捷软件开发研究[D].北京邮电大学,2013.
[3]胡丹.基于关键链的敏捷软件开发项目进度管理研究[D].浙江工业大学,201 3.
[4]谢业亮,昊群飞,戴勇.浅谈敏捷软件开发在电力系统信息化建设中的应用与发展[A].中国电机工程学会电力信息化专业委员会.电力行业信息化优秀论文集2013[C].中国电机工程学会电力信息化专业委员会,201 3(07).
软件过程RUP初探 篇5
韩瀛
（天津财经学院信息系 300222）
摘要：本文介绍了Rational统一过程（RUP）的主要内容，包括开发阶段、迭代过程和核心工作流等，并简要评述了其在软件项目开发中的优越及不足之处。
关键词：统一过程 里程碑
迭代 核心工作流
Abstract: This paper discuss the important contents of the Rational Unified Process, including Development Phase, Iteration Process, Core Workflows and so on. Additionally, giving some comments about its advantages and weaknesses in the software projects development.
Key Words: Unified Process, Milestone, Iteration ,Core Workflows
一 前言
软件过程是指实施于软件开发和维护中的阶段、方法、技术、实践及相关产物(计划、文档、模型、代码、测试用例和手册等)的集合。行之有效的软件过程可以提高开发软件组织的生产效率、提高软件质量、降低成本并减少风险。目前市场上领先的`软件过程主要有RUP(Rational Unified Process)
、OPEN Process和OOSP(Object-Oriented Software Process)。
RUP具有较高认知度的原因之一恐怕是因为其提出者Rational软件公司聚集了面向对象领域三位杰出专家Booch、Rumbaugh和Jacobson，同时它又是面向对象开发的行业标准语言――标准建模语言(UML)的创立者。RUP是由
Objectory过程演化而来，其初始版本为5.0，先后经历了5.1、5.11、5.5等版本直到最新的Rational Unified Process版本。本文主要讨论RUP的主要内容和特点。
二 RUP的二维开发模型
RUP可以用二维坐标来描述。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)
软件开发过程的持续集成探讨 篇6
【关键词】软件开发；持续集成；Jenkins
0.前言
持续集成是一种软件开发实践，对于提高软件开发效率并保障软件开发质量提供了理论基础。本文通过具体实例，介绍了如何借助持续集成工具提高软件生产力。
1.当前公司的版本发布工作
当前各个公司的版本发布工作差异很大，有些公司没有每日编译版本，等到正式发布时发布一下；有些公司则是写一个脚本每天晚上定时编译一下，第二天开发人员就可以使用前一晚上生成的版本；有些公司使用持续集成工具编译版本，代码有更改时就会触发编译；还有些公司根据每日编译的状态触发电子装备，亮红灯或绿灯来显示版本的状态，有些甚至利用发声装备发出导致版本编译失败的代码上传者的名字。
可见各个公司在持续集成方面的投入差异巨大，持续集成投入越多，软件版本交付能力就会越强，软件生产力也就越高。
2.持续集成的核心价值
（1）持续集成中的任何一个环节都是自动完成的无需太多的人工干预，有利于减少重复过程以节省时间、费用和工作量。
（2）持续集成保障了每个时间点上团队成员提交的代码是能成功集成的。换言之，任何时间点都能第一时间发现软件的集成问题，使任意时间发布可部署的软件成为了可能。
（3）持续集成还能利于软件本身的发展趋势，这点在需求不明确或是频繁性变更的情景中尤其重要，持续集成的质量能帮助团队进行有效决策，同时建立团队对开发产品的信心。
3.持续集成的原则包括
（1）需要版本控制软件保障团队成员提交的代码不会导致集成失败。常用的版本控制软件有IBM Rational ClearCase、CVS、SVN等。
（2）开发人员必须及时向版本控制库中提交代码，也必须经常性地从版本控制库中更新代码到本地。
（3）需要有专门的集成服务器来执行集成构建。根据项目的具体实际，集成构建可以被软件的修改来直接触发，也可以定时启动，如每1小时构建一次，还可以由上游项目编译成功后触发。
（4）必须保证构建的成功。如果构建失败，修复构建过程中的错误是优先级最高的工作。一旦修复，需要手动启动一次构建。
4.持续集成工具介绍
4.1持续集成工具主要分两大类，开源的和商用的
（1）开源工具。
CruiseControl、Hudson、LuntBuild
（2）商用工具。
TeamCity、AntHill Pro、Bamboo、QuickBuild
CruiseControl和LuntBuild在持续集成领域进入较早，Hudson作为OpenSource里持续集成的后起之秀，现在已经赶超了这两个前辈，目前恐怕是使用最多的一个CI Server了。国外使用商用的工具多些，而在国内用开源的多些，其中Hudson工具使用较为广泛，现在叫Jenkins，是基于Java开发的一种持续集成工具，它主要包括：
（1）持续的软件版本发布/测试项目。
（2）监控外部调用执行的工作。
4.2 Jenkins具有以下突出的特点
（1）开源免费，容易安装，只需要执行Java-jar jenkins.war即可。
（2）容易配置，可以通过友好的webGUI来配置，几乎每个配置都有帮助信息提示。
（3）跨平台，几乎支持所有的平台，例如Windows，Ubuntu/Debian，RedHat/Fedora/CentOS，MacOSX，openSUSE，FreeBSD，OpenBSD，Solaris/OpenIndiana.Gentoo。
（4）master/slave支持分布式的build，jenkins能够分发build/test的负载到多台机器，能够更好地利用硬件资源，提高build的时间。
（5）插件支持，已有200多个插件，可通过第三方的插件来扩展。
（6）Junit/TestNG测试报告，能够很好地显示各种测试的报告，且可以生成失败的趋向图。
5.应用举例
（1）某产品开发部有驱动、软件等小组，各小组的代码是各自管理的，但接口文件是共同的。假如软件小组的某个头文件修改的时候驱动小组也需要同步修改，该文件受软件小组管理，驱动小组需要同步，如果靠人工每天去看对方的头文件是否更改，比较费时，也容易漏掉。如果你使用Jenkins工具新建一线程，专门检测对方的接口文件，当然对方该部分代码需要给对方小组某成员开读权限，当检测到对方头文件有修改时则将该文件check到本地，然后再check自己的代码，将对方的接口文件上传到自己的库里。完成后再触发邮件系统将邮件发送到相关开发人员。这样开发人员能够把更多的精力花在关键事务上。
（2）上传代码到自动化测试一气呵成。某部门开发一套指纹识别项目，开发人员优化该项目时，由于优化过程是持续累积的过程，每天可能都能提高一点，当开发人员将阶段性的成果上传到代码库中，系统按设置的一定时间间隔完成编译并将编译库放到服务器，自动化测试程序也会每隔一定时间去取这个库，并运行程序，并将运行结果直接发送到开发人员工作信箱里。开发人员也能很快速方便地看到自己优化的结果。
6.结语
工欲善其事，必先利其器。软件开发也要借助于提高软件生产力的工具，持续集成工具能够把开发人员从繁琐的代码同步、版本发布、查找编译失败等工作中解脱出来，让开发人员把精力聚焦在核心业务上。
【参考文献】
试析软件开发过程中的软件测试 篇7
关键词：计算机软件,软件工程,软件测试
在软件刚开始发展的那段时期,测试被认为是毫无技术含量的“猴子的工作”。由于测试在当时完全不受重视,拥有最好的开发过程的开发人员也马上就撞上了质量墙。而在后来的软件发展过程中,又不断有无数知名的计算机软件故障被新闻大肆报道,如因为节约空间省略年份前两位导致在2000年损失几十亿美元的千年虫事件,又如未检测一个接口导致一个数据位的错误设定最终导致的火星登录事故,又如诺顿杀毒软件病毒库更新误杀Windows系统文件的赛门铁克事件。尽管已经有了无数教训,但由于软件错误或缺陷造成的悲剧仍然每天都在上演。而现在,软件测试实际上是被广泛认定为一项需要高超技术能力的行业。之所以称为“行业”是因为软件测试不再向过去那样可有可无,而是在软件开发过程中发展成必不可少的一部分。
1 软件测试的定义、目的
对于软件测试,著名学者Glenford J.Myers认为首先应该认定软件是有错误的,但之后可以通过软件测试去找出这些错误。他还就此提出一些重要的观点,这些观点也可以看作是测试的目标或定义。
测试是为了证明程序有错误,而不是证明它无错误。好的测试用例在于它能发现以前没有发现的错误。成功的测试是发现了以前从未发现过的错误的测试。
软件测试的目的如下:
(1)以最少的时间和人员成本,系统地去发现软件中存在的错误和缺陷。测试的目标就是成功地暴露程序的错误,因此,如果正确实施了测试,就能发现软件中存在的错误。
(2)通过测试证明软件的功能与需求规格说明书的要求相吻合。
软件测试与软件质量息息相关,简言之,软件测试是软件质量的保证。通过测试来发现错误并将其修正,最大程度上规避软件发布后由于潜在缺陷和隐患带来的商业风险是我们所最看重的。
2 软件测试的分类
2.1 基于测试技术的划分
2.1.1 静态测试
静态测试是指在不运行程序的情况下,依靠人工走程序进行分析,也就是平时写小程序时的测试方法。静态测试对软件的需求文档、设计文档及源码等进行检查,主要包括走查、需求确认等。
2.1.2 动态测试
动态测试是让程序运行起来的检查方式,研究程序运行后的外部表现和执行结果。
2.1.3 白盒测试
白盒测试是指通过分析程序的内部结构,检测和寻找问题。在进行白盒测试时,要对程序内部如何运行了如指掌,选出少量“最有效的”测试数据与预期结果进行比对。白盒测试主要包括语句覆盖、判定覆盖、条件覆盖及其中一些组合。
2.1.4 黑盒测试
黑盒测试是与白盒测试互补的方法,它只注重程序的外部表现,而忽略程序的内部执行过程。通过对程序功能的分析,可以发现与白盒测试不同的错误。
2.2 基于测试实施组织的划分
2.2.1 开发方测试
开发方测试是指开发商通过已有的人力和设备资源,站在开发者的角度对软件是否能满足需求规格说明书和软件设计说明书的测试,测试后需要能够提供客观证据证实软件的确通过了开发方测试。
2.2.2 用户测试
在用户所处环境下,安装运行软件,并让用户真实体验软件是否能达到自己的期望要求。用户在使用后,可以提出对软件的改进意见,并对软件进行评价。
2.2.3 第三方测试
第三方测试又叫独立测试,由不属于开发方及用户方的第三方组织对软件进行的测试,通常是在模拟用户使用软件的环境中进行测试。
2.3 基于开发阶段的划分
2.3.1 单元测试
单元测试又称为模块测试,是通常与编码发生在同一个阶段,可以运用人工测试和计算机测试(依靠驱动程序和存根程序)两种方法,对程序模块进行正确性检验的测试工作。单元测试需要从程序的内部结构出发设计测试用例,即采用白盒测试方法,可以对多个测试模块并行测试。
2.3.2 集成测试
集成测试在单元测试之后进行,是将所有的已测模块组装起来的同时进行测试。集成测试着重测试模块间的协调和通信,即模块的接口。此外,每当一个新的模块作为集成测试的一部分加入总体的时候,软件会产生一些变化,这时需要适当地做一些回归测试。
2.3.3 确认测试
确认测试用来检测与证实软件是否满足软件需求说明书中规定的要求。该测试是在用户积极参与下对软件满足所有功能的、行为的和性能的需求的最终保证,其中发现的往往是系统需求说明书中的错误。在确认测试过程中仅使用黑盒测试技术。
2.3.4 系统测试
系统测试是在完全真实的软硬件环境中检查软件系统能否正确地被安装、配置、连接和运行,确定程序最终能满足用户的需求。
3 软件测试的特性
3.1 重要性
软件测试可以保证最终设计出的软件满足需求说明和设计说明并且最终可以成功且稳定地运行,因为这其中任何一个环节出现问题都会在软件测试阶段表现出来。如果测试没有通过,则说明软件确实是在某些方面存在问题。在软件开发过程中,用在测试上的花销要在30%~50%。如果把软件维护阶段考虑在内的话,测试花销会有些降低。但考虑到维护也是软件的再开发及多次开发,其中也包含很多的测试工作。因此,通过对这部分数据的调查得出结论,软件测试在整个软件生命周期需要50%以上的时间和经济成本。总结起来就是,一个好的测试是项目成功的保证,可以大大降低将来的解决错误的成本,发现项目存在甚至潜在的众多问题。而一个不好的测试会影响软件的性能,导致在维护阶段花费巨额成本,甚至影响软件公司的名誉。
3.2 复杂性
软件测试是非常复杂的,因为软件只有在所有可能的路径下输入一切可能的数据全部执行一遍(即穷举测试),才能发现所有错误。但一般情况下,这是不可能发生的。
黑盒法是穷举输入测试,但输入的情况无穷无尽,不仅要考虑正确输入,还要考虑各种错误输入,才能保证程序的健壮性。白盒法是穷举路径测试,而程序的路径数不胜数,难免出现遗漏。而在遗漏的那些路径中,就可能存在着潜在的错误。
3.3 经济性
程序测试能证明存在错误,而不能证明不存在错误。在实际测试中,穷举测试工作量巨大,根本行不通。这说明一切的软件测试都是不彻底的。但软件工程的目标是,充分利用有限的人力、资源、时间尽最大可能进行最高质量的测试。这其中,可以通过对测试部分的轻重缓急排序进行不同程度的测试、研究测试策略等方法降低测试的花销。
4 软件测试的准则
4.1 正面和反面测试都有助于降低风险
正面测试是简单地验证软件是否向其所宣传的那样工作,这对于大家来说很容易理解,但市面上还是经常出现存在各种错误的软件,原因就是“没人测试过这个问题”。而反面测试则是验证确保不会在用户在正常业务使用中破坏。相比于正面测试,它更容易被忽略,还更需要测试人员的创造力。
4.2 静态和运行测试都有助于降低风险
现在大多数软件测试都必须运行程序代码才能完成,但一些人已经开始注意到这样一个事实----软件开发过程中会产生大量文档,如果对这些文档进行静态测试,就可以在没有开始编码前就大幅度地减少运行错误的数目。
4.3 自动测试工具有助于降低风险
在过去几年中,随着自动化性能测试工作变得越来越成熟,人们已经开始在条件允许的情况下尽量考虑用测试工具逐渐代替各种手工测试。
4.4 把最大的风险放在最先测试
当面临有限的测试人员、有限的测试工具和有限的测试时间的时候,就必须保证有足够多的测试资源用来至少把最大的商业风险测试好。
4.5 把最常用的业务行为放到第二个来测试
当测试了最大风险之后,就该选择测试最常用的那些业务行为。根据80/20法则(80%的业务行为由20%的系统功能提供),要确保将工作重点放到20%最重要的系统功能上。
4.6 统计分析错误发生模式和其他错误特征是预测测试完成的重要手段
到现在为止,还没有任何人能宣称他可以对任何规模稍大的商业软件系统进行完全的测试。那么测试人员怎么知道何时测试工作算完成呢?事实上,根据Weibull分布模型,测试人员在预测软件实现中应该发现的错误总数时,可以把误差范围控制在10%~20%。
4.7 像用户使用软件那样来测试软件
所有测试都应该能追溯到用户需求,这一准则看起来是那么的理所当然,但笔者认为,这是软件测试的灵魂。
4.8 测试不只是要花钱,也是一种投资
测试能带来明显好处,不仅能够降低商业风险,还可以大大降低将来维护的工作量,更是对软件的一种长远投资。
5 软件测试的步骤
如图1所示。
6 软件测试的现状、前景
对于软件测试行业的现状,有以下几点:企业越来越重视软件测试,但企业内测试人员所占比例仍然很低。测试行业越来越受人欢迎,但测试人员的实际水平却不尽如人意。这种矛盾反映出软件测试目前是一个巨大的人才缺口,但真正有能力填补这个缺口的人却不多。
对于该行业的前景,Harry Robinson在2004年就曾预测过软件测试的未来,他持有以下的观点:测试的方法日趋完善,测试用例会时常更新,机械化测试将被大量应用;开发人员会加入测试团队,测试与开发的界限将开始模糊,客户反馈都将成为测试的一部分。
7 结语
软件测试是软件生命周期中至关重要的一环,而软件测试行业可以说是“道路是曲折的,前途是光明的”。在所在的大连理工大学国家示范型软件学院进行调查,大部分本科生对软件测试了解甚少,甚至还有很多认识误区,认为测试是浪费时间,每次做项目在测试部分也都是草草了事,结果导致程序在交接后出现各种意想不到的错误
参考文献
[1]芦阳.云计算及其带来的机遇与挑战[J].电脑编程技巧与维护,2013,(2):104-105.
[2]陈明.软件测试.北京:机械工业出版社,2011.
[3]Gerald D.Everett、Raymond McLeod,Jr..Software Testing(Testing Across the Entire Software Development Life Cycle).北京:清华大学出版社(译),2008.
软件缺陷度量与软件过程管理 篇8
软件产品的生产过程是软件质量的形成过程, 所以只有在过程中实现良好的管理和质量控制, 才能得到一个质量合格的软件产品。软件缺陷就是其中的软件质量的负面影响因素。虽然所有的软件系统都不是尽善尽美的, 但是严重的质量问题会危及用户的使用, 从而危及企业的软件生产。
软件的开发阶段的缺陷管理和预防是非常重要的, 因为一旦制定了有问题的软件的设计方案, 会直接导致软件的质量隐患, 所以, 我们在研发阶段要尽可能的防止这种情况的发生, 将隐患扼杀在初始阶段。一般的做法是, 在软件研发的过程中要形成一个严谨的缺陷分析报告, 将关于软件的性能的各个方面的具体数据和资料综合整理出来, 对于存在安全隐患和易出现问题的环节做好一定的预防措施和预防方案。
2 问题描述
缺陷度量的技术的一个重要的指标和重要的作用就是对于软件系统中存在的问题的显示, 也就是对具体问题的描述。一般情况下, 软件的缺陷会分为大致的几种常见类型, 我们也可以根据这些类型, 做出不同的缺陷显示方法。正交分类方法ODC (Orthogonal Defects Classification) 作为一种常见的问题显示方法, 能够准确的显示问题, 一直被业内广泛的使用, 但是它也存在着技术上的缺陷, 就是解读方式比较复杂。另一种常见的方式是Thayer, 有点是比上一种方式的结果更精确, 但是解读起来也更加复杂。这两种方式的共同点在于都忽略了对于软件的过程的监控和分析, 这是一个非常严重的技术问题, 因为软件的研发过程才是质量问题的形成的重要阶段, 要控制质量问题, 就必须控制软件的研发过程, 所以, 我们想要找出新的监管和缺陷度量方法, 就要从控制过程的角度来分析。现在市场上的已经开发了几种缺陷管理系统工具, 例如Mercury公司的Quality Center, IBM公司的Rational系列管理工具, 微软公司的VSTS等。上述的几种技术都没有解决缺陷的分类问题, 导致了在软件过程的管理中的缺陷分类的薄弱。也直接导致了现有的缺陷管理工具在实用性和综合性方面的不完善, 上述的两种管理工具只是提供一些缺陷属性数量的简单统计结果, 要想得到一些更精确和更综合全面的分析结果, 用户不得不借助其他的统计方式。基于该目前市面上的工具的这样一种缺陷, 和软件过程管理的实际需要的不协调, 笔者制定了一种新的管理模型, 如图1。该模型可根据需要设计缺陷属性度量分类标准。在软件开发过程中通过缺陷管理系统采集缺陷数据, 运用缺陷分析方法实施缺陷分析, 把握缺陷发展趋势, 对软件项目开发过程进行综合评价。实施缺陷预防方案, 提高软件产品的开发质量。通过缺陷分析结果的反馈, 改进缺陷度量分类标准和分析目标, 提高缺陷分析结果的准确性。本文重点研究了缺陷分类方法和缺陷数据的分析方法, 并结合某项目中的缺陷数据实例进行了分析。
3 缺陷分类方法研究
3.1 缺陷分类的目的和原则
将软件的缺陷问题分类, 可以更好的管理和击破软件的缺陷问题。并且有益于分析缺陷产生的原因, 可以早到有计划的预防。缺陷分类方法应满足以下要求:准确地对发现的缺陷类型进行分类;缺陷分类类型之间应无重叠, 并尽可能多的覆盖开发过程中出现的分类;分类要与软件生命周期有机结合, 从软件过程的角度对软件缺陷进行分类。
3.2 缺陷度量属性分类
实施度量分析的最终目的是为了服务软件的研发和试验的各个阶段的顺利进行, 一旦发现问题可以及时纠正, 以免影响软件的研发和生产。在引言中曾提到, 软件缺陷的范围很广, 它贯穿于整个软件研发和生产试验的各个阶段, 是一种伴随着软件的整个过程的始终的应用, 所以它的重要程度也可想而知。一个缺陷需要记录许多相关的度量属性, 如何划分这些度量属性也是缺陷分类研究领域的一个热点。传统的分类方法主要目标是消除软件缺陷, 而不是对缺陷出现的原因进行一个正确的评估和解决方案的分析, 这样的分类方法是不利于软件的完善和发展的。所以, 一个全方位多角度的缺陷度量方式就应运而生。下面本文中将从缺陷度量属性设计的三个方面, 即描述属性、统计属性和控制属性来进行具体阐述。a.缺陷描述属性。缺陷描述属性是指:缺陷信息描述, 对于缺陷的各个方面和各个角度的描述, 既包括缺陷的时间, 产生原因也包括具体的解决方案的策划。b.缺陷统计属性。缺陷统计属性是指:缺陷生命周期状态, 缺陷流出的开发阶段, 缺陷流出的部门, 缺陷流出的功能模块, 缺陷表现类型, 缺陷的严重等级等基于缺陷数量统计其分布的属性。并且缺陷统计属性参考正交缺陷分类方法划分, 属性间没有相关性。c.缺陷控制属性缺陷控制属性是指:处理缺陷的角色, 缺陷的分配, 处理缺陷的时间, 缺陷数据之间的关联关系等基于缺陷分配流程管理的属性。
4 缺陷度量过程管理
4.1 处理缺陷的角色
在软件开发过程中处理缺陷的四个负责人和所负责的任务的具体情况:报告人:将发现的缺陷登录到缺陷管理系统, 描述缺陷的表现形式和再现方法, 对缺陷进行简单分类, 由项目经理、组长对缺陷进行再分配, 缺陷修正完成后, 对其进行回归测试审核。负责人:负责缺陷的调查和修正工作, 分析缺陷引入的原因。组长:分配缺陷到负责人, 并对负责人已修正缺陷进行复查, 确保不会因为修正而引入新的缺陷产生, 分析缺陷流出原因。项目经理:分配缺陷到项目组, 定期总结缺陷分析报告, 把握缺陷发展趋势, 采取应对措施保证项目的进度及开发质量, 根据缺陷分析结果改进缺陷度量属性分类。
4.2 缺陷生命周期
缺陷生命周期是指缺陷从被报出之后, 到开始修正, 再测试直到该缺陷被完全消除的时间段。缺陷生命周期是影响软件研发的一个重要的指标和因素, 定期对缺陷各种状态信息的变化趋势进行总结, 是项目经理计划开发周期, 调整开发进度的重要依据。
4.3 缺陷分配管理流程
整个的缺陷的周期主要是指从发现到完全消灭的时间, 在这个时间内, 缺陷的分配管理流程主要包括:a.报告人登陆缺陷;b.管理人员分配缺陷给相关责任人;c.责任人调查并修正缺陷, 分析缺陷引入的原因;d.管理人员对修正结果进行复查, 分析缺陷流出的原因;e.报告人验证缺陷是否被正确。
结束语
软件的研发是一项非常复杂和严谨的工程, 所以在这个阶段要对软件的质量作出各个方面的监测和试验, 这样才能最大程度上减少软件的质量问题的发生概率, 而软件缺陷度量作为软件质量监测的一个重要方式, 应该引起我们有关的工程人员的足够重视, 不断在缺陷度量的技术上提升, 这样才更好的服务于我们的软件研发工作。
参考文献
[1]何荣勤.CRM原理.设计.实践[M].北京:电子工业出版社, 2006.
全过程软件测试 篇9
同行评审在能力成熟度模型(Capability Maturity Model Integration,CMMI)集成中是VER(VE-FICATION)验证的一个特殊目标(SG),在CMMI的诸多子过程中,同行评审几乎贯穿整个软件生命周期,自始至终扮演着重要的角色。同行评审对于广大软件开发人员和软件组织来说并不陌生,通过同行评审,能够及早识别并消除缺陷,从而极大减少在软件开发后期运维阶段消除缺陷所要付出的代价。尽管同行评审被认同是一种发现缺陷、获取软件过程信息的有效方法,但在我国众多软件企业中,同行评审的应用对象大多仅限于需求、设计文档,鲜有针对软件测试活动对象的同行评审。事实上,同行评审也是软件测试过程中的重要环节,软件测试过程也离不开同行评审活动。同行评审活动实施的有效性也影响着测试过程活动的效率和质量。针对上述现象,文章分析了同行评审在软件测试过程中开展的必要条件,提出了软件测试过程中同行评审的重要节点、应用对象以及评审重点,证明同行评审的有效开展对提高测试工作质量起着非常重要的作用。
1 同行评审的条件和节点
同行评审,其定义为“由软件工作产品生产者的同行遵循已定义的规程对产品进行的技术评审”[1]。
1.1 同行评审的开展条件
做好同行评审,使同行评审发挥其应有的作用,需要一些必须的前提条件,否则,同行评审活动无法达到预想的效果,甚至会被认为是一项额外的负担而使测试人员产生抵触情绪。必要的前提条件包括如下方面[2,3,4]:
(1)同行评审需要管理层支持:如果缺少管理者支持,即使是目标明确的开发成员和测试人员也会抵制评审。管理层的支持包括建立评审策略和目标,提供资源、时间、培训和激励,并遵守评审小组的决定等。
(2)组织内部对评审工作应制定相关的标准和规范,建立组织级过程:组织级应有一个针对同行评审的指导书或规程或系列培训,针对每种类型的评审应制定通用的工作产品评审检查表,必要时可以进行裁剪以适应特定项目的要求,应规定同行评审的入口和出口准则,评审开始应当符合入口准则,评审的结束应该符合出口准则,否则同行评审做法不一,难以保证评审效果。
(3)做好相关人员的培训:为使评审相关人员深入地了解和掌握评审规程,认识评审的重要性,学会正确使用评审和开展评审,组织应对所有与评审相关的人员开展评审相关规程的培训,将正确的评审方式进行宣传贯彻,为同行评审的顺利实施打好基础。
(4)有效的过程实施:建立好标准和规范是过程实施的前提,但过程实施的有效性却依托于企业的文化氛围以及监督管理机制。
(5)正确的规划计划:评审的问题很大一部分出现在准备上。评审组织者应认真制定评审计划,若计划有变更要及时调整,保证评审计划可实施。评审计划包括评审专家组成、评审文档准备、预审时间和评审时间规划、评审检查单准备、评审问题的整改时间规划等。
(6)足够的资源:要保证评审的效果首先应当保证资源,不但要保证评审的资源是质量合格且数量充足的,也要保证被评审的资源,使他们能及时地修改错误。
1.2 软件测试周期中的同行评审节点
很多企业中,项目管理者存在重开发轻测试的现象,对测试的重视和策划程度尚不够充分,更不会重视测试过程中的同行评审的策划,往往是在软件需求评审时附带软件测试计划评审,在软件设计评审时附带测试设计的评审,而评审专家中缺少测试领域的专家,导致在评审有效时间内,软件测试计划和测试设计的内容并没有得到充分的审查,进而也会影响测试工作的有效性和充分性。
为使软件测试过程中的各项活动保持良好的需求追溯性,保证测试工作始终受控,降低返工,保障测试工作有效和充分开展,软件测试周期中建议的同行评审主要活动节点如图1所示。
2 同行评审的应用
2.1 软件测试过程中同行评审应用的主要对象和评审重点
同行评审适用于软件形成过程中产生的任何可阅读的工作产品,包括:软件(如源代码)和非软件工作产品(如需求等)、可交付的和不交付的软件工作产品。
软件测试过程和软件开发过程一样,都遵循软件工程原理[5],其过程一般分5个阶段,即测试需求分析、测试策划、测试设计与实现、测试执行、测试总结。它是一个完整的全面过程,每个阶段的输出是下一个阶段的输入,一系列测试工作产品,如测试需求规格说明、测试计划、测试说明(含测试用例)、测试执行记录、测试问题报告、测试报告,在每一轮次都将产生。这一系列文档是软件测试过程的主要工作体现,应作为测试阶段的同行评审对象。
代码审查/代码走查是测试过程中针对软件代码的一种同行评审。代码审查是根据已确定的检查单通过阅读代码的方式对程序进行静态检查的过程;代码走查是由测试人员组成小组,准备一批有代表性的测试用例,集体扮演计算机的角色,沿程序的逻辑,逐步运行测试用例,查找被测软件缺陷的过程。代码审查侧重于检查代码和设计的一致性、代码执行标准的情况、代码逻辑表达的正确性、代码结构的合理性以及代码的可读性;而代码走查则侧重于程序逻辑实现的正确性,所以它也经常作为逻辑测试无法实现动态100%语句/分支覆盖时的一种静态补充手段。代码审查/代码走查都是早期发现软件代码缺陷的一种同行评审。
表1给出了软件测试过程中同行评审的主要应用对象和评审重点。
2.2 软件测试过程中同行评审发现问题的定位
同行评审发现的问题与测试发现的问题一样,同样有问题严重等级之分,而且,对问题的等级定位也是很多企业在开展同行评审之前要先达成一致标准的问题之一,但业界目前尚无相关标准用于判断同行评审发现的问题属于严重或一般,但通过大量工程实践的经验总结,对于测试文档的同行评审,一般情况下问题的界定原则如下:
(1)该问题若不被发现,将会导致多个产品缺陷遗留至后期的测试阶段甚至是用户使用阶段被发现,界定为严重问题。
(2)测试设计的问题,该问题将导致一系列测试用例的失效,界定为严重问题。
(3)该问题的发现和解决,可以作为如何提高测试能力的典型案例,界定为严重问题。
(4)其他问题界定为一般问题。
对于软件代码同行评审过程中发现的问题,一般情况下问题的界定原则如下:
(1)该问题若不被发现,将会导致多个产品缺陷遗留至测试阶段甚至是用户使用阶段被发现,界定为严重问题。
(2)软件代码注释中问题,界定为一般问题。
(3)该软件代码问题不会导致编译结果文件的改变,界定为一般问题。
2.3 软件测试过程中开展同行评审的意义
同行评审的实施在软件生命周期中,包括软件测试过程中的作用如图2所示。
软件测试过程中开展同行评审的意义如下:
(1)提高生产率:代码走查或代码审查等类型的同行评审活动先于软件动态测试实施,可以使软件缺陷暴露在静态测试阶段,避免了软件动态测试需要付出的问题定位时间、代码重新编译重新集成时间、回归测试时间等,所以测试过程早期的同行评审活动间接地节约了软件生产时间。
(2)降低测试成本,缩短测试周期:通过对测试策略、测试计划、测试场景/用例等内容的同行评审,可以提高软件测试设计工作的充分性和合理性,为测试执行提供更有把握的准则,始终保持测试追溯的完整性。统计资料显示可能节省的测试工作量可达50%或许更多[4],因而可以避免不必要的测试返工,降低测试成本,缩短测试周期。
(3)促进测试团队沟通与知识共享:在测试团队中,团队整体的学习与沟通是非常必要的,通过相互之间的讨论,澄清一些模糊的认识,进一步达成对测试工作目的和标准的一致理解,同行评审不但可以作为测试过程中重要的质量控制机制,也是一个重要而有效的沟通方式。通过评审可以利用各种优秀成员的智慧,为软件测试寻找最佳的解决方案。
3 结束语
同行评审是保障软件测试质量的重要措施之一,固然同行评审的准备、活动和跟踪需要花费一定的时间和工作量,但在测试中可以节省更多。测试过程中的同行评审活动能够在早期发现测试策略和测试设计的错误和不足,使测试进度安排更加合理,建立测试团队对测试活动的一致理解,减少测试的失败成本(包括返工、变更、重新测试等造成的损失)。这样一来,在综合考虑了同行评审活动成本的情况下,同行评审活动也会使测试成本下降50%~80%。所以,重视和加强测试过程中的同行评审,将更加有助于提高软件的缺陷清除率,有效保障软件的质量和可靠性。
参考文献
[1]景慎艳.软件项目的同行评审[J].电脑开发与应用,2011,24(11):68-70.
[2]张文秀,张锦辉.软件过程中同行评审的应用与度量[J].计算机应用与软件,2008,25(10):101-102.
[3]张万军,储善忠.基于CMMI的软件工程教程[M].北京:清华大学出版社,2008.
[4]刘从越,张洪霞.论软件评审在军用软件质量控制中的作用[J].计算机工程与设计,2009,30(8):1901-1902.
全过程软件测试 篇10
计算机的应用愈加广泛和深入, 计算机软件也变得愈加复杂, 随之而来软件测试的工作量也变得庞大起来, 设计开发一套完整的软件测试过程的控制和管理系统迫在眉睫。传统的人工控制和管理手段是不可能对软件测试的所有过程进行科学合理的控制和管理的, 于是软件测试过程控制软件和工具应运而生。软件测试过程控制软件和工具能够科学合理地对软件测试过程进行控制和管理, 从而保证了软件测试的质量、控制了软件测试的成本、压缩了软件测试的周期。
2 软件测试过程控制系统的需求分析和设计
2.1 系统总体需求分析
开发一个软件测试平台也是一个软件工程, 涉及的因素很多, 同时也要考虑到可靠性、可用性、成本时间等因素;软件测试也是一个工程同样涉及到可靠性、可用性、成本时间等因素。所以要设计好一个软件测试过程控制系统, 不仅需要深刻理解软件测试工程, 也要深刻的理解软件工程。该系统应该实现以下功能:①目标是为了实现软件测试的自动化, 并为自动化测试提供强有力的管理功能;②软件应该是GUI形式的交互界面, 方便使用和管理、易于理解;③能对软件测试过程进行管理和控制;④能对软件测试人员和测试工具进行安排和调度;⑤能实现测试数据管理和共享。
2.2 制订测试软件计划模块的需求分析
当进行一个新测试项目的时候, 在软件测试过程控制系统输入新测试项目的相关数据:测试项目类型、预计的主要测试项目、预计的测试周期, 软件测试过程控制系统就会根据以往的数据库信息给出推荐测试计划安排。包括:项目测试经理 (通过以往数据和当前的要求进行自动匹配找到最适合该测试项目的经理) 、各个测试阶段的时间分配 (根据当前数据和以往数据进行对比分析得出) 、需要的测试人员数量 (根据当前给定的测试量, 测试周期和以往数据库中分析出的人均每天工作量得出) 、测试开销 (根据数据库中的工资水平和工作量计算得出) 。
2.3 设计软件测试流程模块的需求分析
软件测试的步骤一般可分为:单元测试、集成测试、系统测试、验收测试、回归测试等。
2.4 软件执行测试模块的需求分析
软件的执行测试是软件测试的实际过程, 也是其核心过程。软件自动化测试水平的高低取决于软件执行测试水平的高低。在该系统中软件执行测试主要依靠QTP软件自动化测试工具。所以软件测试过程的控制系统不单单要能为QTP自动化测试工具提供测试数据和测试样例也要能够分析和处理QTP产生的数据和相关信息, 并以数据库的形式对这些数据和信息进行管理和利用。同时软件测试过程的控制系统还要能够调用QTP的一些自动化测试功能, 使得QTP能够科学合理地融入到软件测试过程的控制系统当中, 使得软件测试过程的控制系统的可用性和易用性都能够提高。
2.5 测试总结模块的需求分析
当单元测试、集成测试、验收测试、回归测试等测试完成后, 软件测试过程的控制系统需要对当前测试项目进行总结, 并提取分析相关数据:测试项目类型、预计的主要测试项目、预计的测试周期、项目测试经理、各个测试阶段的时间分配、需要的测试人员数量、测试开销等等。并把这些数据存入数据库, 为以后项目的自动生成一些推荐参数提供强有力的数据支持。同时, 通过对相关的数据的收集和处理, 可以生成当前测试项目的报表, 报表包含了很多有用的信息和数据, 可以对这个项目进行各个方面的评价和评定。
2.6 软件工作流程分析
软件的测试过程是个逻辑判断的过程, 而不是简单的是非判断过程, 所以测试平台必须要有科学合理的逻辑关系, 流程图是表达复杂逻辑关系的有效途径, 所以在测试平台开发前需要设计好流程图以便很好的指导平台的开发设计。而流程分析是基于需求分析的, 所以在需求分析完成后可以对测试软件开发流程进行设计。本设计采用模块化的方法, 使得各个功能模块既能够独立完成相应的功能又能够组成一个有机的整体, 从而实现总体功能。软件测试过程的控制系统不仅要为软件的测试提供测试数据、管理软件测试的过程, 也要对软件测试过程中的人力、物力、时间等因素进行管理和优化从而体现了软件测试的工程性。
3 软件实现和项目验证
选择创建新的软件测试项目后, 按照软件的提示, 并根据上文中该软件测试项目的总体需求分析和测试要求输入相应的项目名称、项目类型、项目预计时间、项目测试内容。创建的软件测试项目界面如图1所示。
输入相关数据并执行后, 系统就会自动生成测试计划, 包括选择哪个测试经理、安排哪些测试人员、每个测试人员具体负责哪些测试项目、各个测试阶段的时间分配、测试设备的调配和安排、测试成本的估算等。这些自动生成的数据比传统软件测试过程中人工设计的数据有着更高的科学性和合理性。生成的测试计划界面如图2所示。
通过这些数据提供的信息, 测试部门的总经理就可以指派测试项目经理, 然后把这些信息和管理权限进行相应的授权和派发后就可以开始这个软件测试项目了。
图3就是单元测试模块中的管理模块, 主要包括单元测试进度管理、异常进度预警管理和测试文档管理等功能。
在单元测试进度管理模块中, 可以实时显示各个单元测试模块的测试进度和已测试项目占总测试项目的百分比等测试进度信息。而且系统会对项目进度自动进行分类, 分别列出进度正常的项目和进度异常的项目, 同时对异常给出原因。根据这些信息测试项目经理可以实时了解测试项目的进度, 然后可以根据数据对测试计划和测试人员安排进行调整。单元测试进度管理的执行界面如图4所示。
在测试的各个阶段都会形成不同的文档, 测试文档管理模块则会对在测试过程中形成的各种文档按照不同的属性进行管理, 按照文档形成的日期进行顺序编号。从而形成了分类科学、种类齐全的测试管理文档。文档管理的界面如图5所示。
该系统能够对bug信息进行管理, 测试员按照系统的填写要求向系统提交bug的详细信息, 测试员可以通过系统获得自己编写代码的bug信息, 对bug进行修改后, 向系统提交修改后的bug信息和相关程序。然后, 测试员可以对该修改过的代码进行重新测试, 然后继续向系统反馈, 直到修正发现的全部bug为止。bug信息反馈界面如图6所示。
其他测试过程如:集成测试、系统测试、验收测试和回归测试的管理功能模块和单元测试的管理模块基本类似, 只是针对各自的特点进行了相应的修改。鉴于篇幅不再一一列举。
当测试过程结束后系统可以生成该软件测试过程的分析报表, 为该软件测试项目进行科学合理的评价。图7为生成的项目报表。
4结束语
软件测试的最终目的就是发现对改善软件产品和软件开发过程有益的信息, 故软件测试是一个信息获取的过程。而传统的测试过程是如此的复杂。本文的创新之处在于设计出的软件测试过程控制系统不仅仅能对软件测试过程进行管理, 还能通过以往的数据进行分析和相关性计算, 对软件测试过程进行决策和调度, 使得软件测试过程趋于合理和科学, 避免主观和随意。
参考文献
[1]RON PATTON.软件测试 (第2版) [M].北京:机械工业出版社, 2006.
[2]赵晓华.计算机软件可靠性与质量管理[M].北京:中国经济出版社, 1992.
[3]徐仁佐.软件可靠性工程[M].北京:清华大学出版社, 2007.
[4]赵斌.软件测试技术经典教程[M].北京:科学出版社, 2007.
全过程软件测试 篇11
关键词 高校管理 教务管理信息系统 发展
中图分类号：TP3 文献标识码：A
1教务管理信息系统的初形和功能
社会在发展，科技在创新，计算机已成为人类进步的关键技能和因素。教务管理软件的发展是随着计算机的发展而发展的，它是从原有单一的程序到可实现多个功能的程序集合，即教务管理子系统的初形。因此，我们可以从计算机的操作系统和相关数据库系统软件的发展来分析教务管理软件的演变过程。
1.1教务管理信息系统的初形
1987年2月，在数据库系统软件应用方面，美国FOX公司推出了多用户关系型数据库管理系统，FOXBASE+系统，由于其性能优越，很快在我国得到广泛的应用和普及。由于我国计算机发展的滞后，在90年代中，教务管理人员提出把实现单一功能的程序集合起来的要求，很快程序开发人员把这些实现单一功能的程序进行分类集结，形成可实现多个功能的程序集合，此时的教务管理软件功能开始增强，处理的数据也增多了，开始形成教务管理子系统的初形。
1.2教务管理信息系统的功能
我国的计算机发展相对比西方慢，在90年代初，才利用数据库管理系统进行编程，应用到教务管理上，当时的教务管理信息系统算不上是系统，只是一些实现单一功能的程序。这些程序有：学生学籍数据录入程序，打印学生名单、打印各类成绩单等。
2教务管理信息系统的形成过程
教育事业正在高速发展，高校和高职院校的数量显著增长，学校办学规模不断扩大，学生人数不断增长，这些变化对原有高校的教务管理信息系统提出了更多的要求和功能。随着计算机技术的不断发展，开发教务管理信息系统所采用的操作平台、开发工具和后台的数据库管理系统有很多。该系统主要是由各子系统组合而成的，已实现多种功能为主，同时达到远程数据传送效果。这个阶段采用DOS操作系统，数据库软件方面有更高版本的FOXPRO。如FOXPRO 2.6 FOR DOS，它是一套关联型数据库管理系统程序，其功能完整，用户界面比较友好，便利阅读的表格来编排数据元素的，使用户轻易地储存、组织、管理及打印平日工作上的各种数据，因此用这套软件开发教务管理系统的学校很多，并且有计算机公司开始参与开发，专业技术开发人员介入到教务管理信息系统的开发中。
操作平台方面有Windows、UNIX、Linux。作为一个处理数据量相对不算大的教务管理信息系统，采用Windows操作系统已基本足够了。计算机网络技术的快速发展，以及为了满足应用软件在网络上的使用，微软公司在2000年推出了构建于客户机/服务体系结构的Windows2000系列操作系统，实现用户应用软件的网上操作，数据共享。前台开发工具方面，采用Power Builder、Delphi、ASP.NET、FrontPage等，而采用Power Builder作为前台开发工具的用户比较多，它是目前较流行的开发工具。后台数据库管理系统应用方面也有很多，如规模较大的采用SQL Server、Oracle、Sybase等大型数据库，规模较小的采用Acces、Foxpro等小型数据库。
3教务管理信息系统的发展趋势
为了落实教育部的《面向21世纪教育振兴行动计划》安排，推动教学资源建设，推广现代化教育技术在教学和教学管理中的应用，促进教育整体质量和办学效益的提高。从教育主管部门，到各高校以及计算机技术开发公司都积极面对，通过多方技术支持参与和开发教务软件，到两方面的发展势头。
3.1教育部门的推动力量
国家教育部信息中心作为全国高校管理软件的推广、培训部门，一直致力于高校教务管理软件系统的开发工作，它所开发的《高等院校教务综合管理系统》，从教务管理的实际流程出发，将所有数据处理集成在一起，实现真正数据共享，彻底解决数据安全性问题，为教务管理人员解决了很多烦琐的工作，减轻工作的负担。
3.2学校的研发力量
随着学校办学规模的不断扩大，管理水平不断提高，原有的管理模式和手工处理方式已很难跟上形势发展的步伐，只有运用信息技术进行科学管理，才会有助于提高教育管理工作效率。因此，很多高校根据自己的实际，充分利用学校的人才资源和技术资源，自行开发适合自己学校管理的教务管理信息系统。为各级学校开发校园网，开发教务管理信息系统以及办公自动化系统，大大提高学校的教育和教学管理的效果。
总之，学校的主要工作重点是教学工作，如何科学高效的落实教学工作，为教学工作做好统筹、规划和服务。计算机的教务管理信息系统是当今学校提高教务管理工作效率的重要手段，只有科学高效的灵活运用教务管理系统，才能使学校更加重视系统内容，也有效的助推了系统的应用和研发，从而加快了学校信息化管理的进程。
参考文献
[1] 吴企渊，梁燕等.计算机操作系统[M].北京：清华大学出版社，2000.
[2] 陶志穗等.计算机应用初级教程[M].广州：广东高等教育出版社 ，2003.
[3] 朱爱民等.Power Builder9.0与系统开发[M].北京：清华大学出版社，2003.
全过程软件测试 篇12
近年来,国内越来越多的企业开始实施CMMI,逐步开始或者已经建立了符合CMMI模型要求的过程体系。CMMI成熟度二级中包含了一个叫做度量与分析(Measurement and Analysis)的过程域,换句话说,无论是根据CMMI成熟度二级还是三级建立组织过程,都必须对软件开发过程进行度量。
实际上,软件度量并不是CMMI创造的新概念,上世纪80年代,DeMillo和Lipton就描述了度量理论与软件度量的关系[1]。之后,与软件度量及模型相关的文章书籍相继出现,越来越多的研究人员及工程实践人员开始关注这个领域的发展。毫无疑问,使用度量对软件开发过程进行管理是提高产品质量的有效手段。
但是,由于国内许多实施CMMI的组织对于软件工程的理解不足,导致了在建立度量目标、度量项以及进行度量分析时过于依赖外部专家,而对于组织的商业目标、度量模型以及如何使用度量数据并不理解,更多是因为“模型需要”而进行度量活动。
本文目的是为正在建立CMMI过程体系或已经建立但希望在度量方面进行改进的组织提供一定的参考。
1 测试过程度量
过程改进的重要目的就是提高软件产品的质量。而软件质量工程的本质就是研究过程(in-process)度量、项目特征以及最终产品质量的关系[2]。提高软件质量的方法有很多种,包括测试(本文的测试包含静态测试——评审检查以及动态测试)以及质量保证(QA)。而实际上国内许多企业对于QA的实践不足,因此本文在这样的背景下,介绍测试过程的相关度量以及分析方法。
关于如何开展度量活动,实际上CMMI模型MA(Measurement and Analysis)过程域的一些特定实践(SP)也提供了相应的参考[3]。这些实践包括:(1)SP1.1——建立度量目标;(2)SP1.2——确定度量项;(3)SP1.4——确定分析程序。
在建立度量项以及分析方法时,组织既可以按照CMMI模型中已定的顺序,也可以循环地开展以上3个实践。
对于软件测试过程的度量项建立,我们可以参考GQM(Goal Question Metric,目标—问题—度量)方法。该方法的假设是组织首先确定组织目标以及项目目标,之后根据目标对过程、产品进行度量,度量数据必须与目标建立追溯关系,最后的度量数据能够反应目标实现的情况[4]。GQM的方法将度量体系分为3个层次:
(1)概念层(目标):更确切地说,这里的目标是指度量目标,可能是组织目标的一部分,也可能是组织目标的分解子目标。度量目标是指进行度量及分析活动的目的,是由于特定的原因,在特定的环境、过程下,根据特定的观点定义对象。
(2)操作层(问题):设定一系列的问题,通过了解目标对象的特征描述特定目标的实现情况。
(3)量化层(度量项):设定一系列的数据对所提出的问题进行量化回答。
如何为软件测试过程设立相应的目标、问题以及度量项就成为了关键。每个目标可以通过识别其三个坐标——对象(Object)、问题(Issue)、观察角度(Viewpoint)以及目的(Purpose)来确定。例如:
对象:集成测试
问题:效率
观察角度:项目经理
目的:提高
因此,我们设立了这样一个目标——提高集成测试的效率。
对象可以是过程或者产品,问题是对象的一个属性,而对于观察角度,由于选取的度量目标不可能与组织中的所有人员相关,必须在建立度量目标时,识别该过程或产品的相关人。
确定了度量目标之后,需要根据目标提出问题。这些问题可以是关于目标如何实现的或者是目标实现带来的结果[5]。例如对于上文提到的目标,可以提出以下几个问题:
(1)集成测试周期持续时间多长?
(2)集成测试阶段的缺陷移除率如何?
(3)集成测试阶段没有发现的缺陷引起的返工工作量是多少?
制定了符合目标要求的问题后,需要识别相应的度量,这些度量应该能够表现目标是否被实现,也可以认为是对于之前识别问题的量化回答。
对于度量的选择,可能来源于客观的数据,也有可能来源于主观的数据。例如,对于缺陷移除率的度量,由于对象明确,数据获取也不困难,使用客观的统计数据有助于明确地回答“问题”。而对于某些度量,例如客户满意度,由于缺少公认有效的理论模型或操作难度大,一些组织对于该度量的设定更多考虑的是客户对于产品的主观印象。
测试过程相关度量项需要根据组织的特点及需要进行选择。例如组织希望了解软件开发生命周期的薄弱点加以改进,那么可以收集所有缺陷,并对其引入阶段进行分析,统计开发过程各阶段的缺陷引入情况,并通过一定的分析确定改进机会。这些缺陷包括了评审发现的缺陷,单元测试、集成测试等内部测试发现的缺陷,以及验收测试和维护阶段发现的缺陷。
2 测试度量数据分析方法
度量的目的并不是收集数据,更重要的是通过对数据的分析了解过程、项目以及最终产品的状况,找到问题及改进机会。本小节介绍与测试度量相关的分析方法。
2.1 缺陷到达模式(Defect Arrival Pattern)
很多组织都会度量软件的缺陷率,希望能够通过该数据了解软件产品的质量以及可靠程度。各组织对缺陷个数的定义可能并不一致,有的组织仅收集发布前的遗留缺陷,有的组织还收集产品试运行阶段所发现的缺陷。但是实际开发的经验表明,交付前缺陷率相近的产品,其交付后所表现的质量可能完全不同。也就是说,在决定一个产品是否能够发布的时候,除了软件缺陷率,我们还需要其他的信息用以决策。缺陷到达模式就是其中一个可供使用的工具。
每个组织的开发模型可能类似于瀑布模型,也可能采用迭代开发模型,无论是哪一种方式,测试活动都会持续一定的时间。在整个测试过程中,可以记录各个测试时间段或者各次迭代测试发现缺陷的总数,之后描绘出类似于图1的图(X轴代表时间/次数,Y轴代表测试发现的缺陷数)。
图1记录了发布前缺陷率接近的两种软件产品的测试状况,然而两种产品的可靠程度截然不同。图1(a)展示的测试状况说明了该产品在早期就投入了大量测试工作,在产品发布前,缺陷数已经收敛;而图1(b)则说明该产品测试不足,这个时候进行产品发布会有较大的质量风险。软件开发中有一个基本的概念:越早发现缺陷,修复缺陷付出的代价越小。项目组通过对曲线的特征判断各阶段测试活动的充分性。需要指出,曲线的形态与模块的设计以及集成的顺序有关。
另外,测试是一个无止尽的活动,测试什么时候能够结束,产品什么时候才能发布也可能困扰着项目组。既然零缺陷发布的情况很少,我们只能选择产品缺陷率稳定在一个相对较低的水平后再进行发布。缺陷到达模式就能够给予我们一定的参考信息。
如果将测试的范畴扩大到技术评审,统计从需求开发、设计、编码到测试发现的缺陷率,X轴按照软件开发的阶段进行区域划分,那么可以得到各阶段的缺陷到达模式。从图中我们可以判断哪些阶段评审投入时间或效率不足,这种信息既能帮助项目作出及时的调整,也能帮助组织识别改进机会。
2.2 缺陷移除率(Defect Removal Effectiveness)
上文提到使用基于开发阶段的缺陷到达模式统计各阶段验证活动的投入是否充足,然而在计算效率时不能忽略另外一个参数——缺陷注入数。缺陷移除率就是用于表现阶段缺陷发现数以及缺陷注入数的关系。
缺陷移除率有不同的定义。以下列举出几种:
(1)Fagan(1976)定义为:
通过检查发现的缺陷数/检查前存在产品中的缺陷数*100%
(2)Jones(1986)定义为:
发现的缺陷数/(发现的缺陷数+之后发现的缺陷数)*100%
(3)Dunn(1987)定义为:
本阶段发现的缺陷数/(本阶段发现的缺陷数+后面阶段发现的缺陷数)*100%
Fagan的定义与Jones的较为类似,而Dunn的定义则与前者有细微差别。以表1数据为例:
根据Fagan及Jones的定义,集成测试阶段的缺陷移除率:
DRE=集成测试阶段发现的缺陷数/集成测试阶段存在的缺陷数=91/(50+77+97+2-7-22-60)=66%
根据Dunn的定义,集成测试阶段的缺陷移除率:
DRE=集成阶段发现的缺陷数/(集成测试阶段发现的缺陷数+系统测试阶段发现的缺陷数)=91/(91+49)=65%
可见Fagan与Jones的定义关注于某一阶段发现的缺陷数与该阶段存在缺陷数的比例,而Dunn的定义则关注本阶段发现的缺陷数与之后各阶段发现缺陷数的比例。无论使用何种定义,不难发现,缺陷移除率的度量具有滞后性,即某一阶段的缺陷移除率必须等到项目结束或者较晚才能得到,但是对于开发者而言同样具有意义。根据缺陷移除率的度量,开发者能够掌握开发过程中验证活动在各阶段的效率,能够有针对地改进验证过程,尽早地遏制缺陷的扩大。其次,通过对以往类似项目度量数据的比对,开发者能够合理地推测各阶段缺陷移除率的水平,从而预测软件产品的缺陷分布,并且制定相应的质量保证计划,既能够有效地提高软件产品的质量,又能够合理地分配资源,避免漫无目的地测试。
3 结束语
数据的收集及分析都需要花费时间和成本,而小规模企业往往考虑使用最少的资源实现度量实践,却忽略了度量的真正意义。缺少有效的需求调研及良好的设计开发,表面上看似缩短了交付周期,但是实际返工带来的投入往往是巨大而且不可控的。缺陷移除率能够帮助管理者发现开发过程的不足,以制定符合企业特点的调整策略。而对于缺陷到达模式的使用,小规模团队可以在测试的最后阶段使用,并且对关键缺陷进行统计,通过对缺陷检出趋势的观察来判断软件是否到达稳定状态足以发布。紧密地将组织目标与度量实践联系在一起,才能使度量真正地支持开发管理活动,获得更大的投资回报。
摘要：描述度量在测试过程中的使用方法。首先介绍了GQM的方法,并介绍了GQM方法针对测试度量的应用。之后对于数据如何使用及分析,介绍了两种分析方法:缺陷到达模式以及缺陷移除率,并比较了两种对于缺陷移除率计算方法的异同点。最后,针对小型企业如何进行测试度量,提出了建议。
关键词：软件开发,CMMI,GQM,度量,测试
参考文献
[1]Norman Fenton.Software Measurement:A Necessary Scientific Ba-sis[J].IEEE Transaction on Software Engineering,1994(3).
[2]Stephen H.Kan.Metrics and Models in Software Quality Engineer-ing,Second Edition[M].US:Pearson Education,1995.
[3]Victor R.Basili,Gianluigi Caldiera,H.Dieter Rombach.The Goal Question Metric Approach[M].Encyclopedia of Software engineer-ing,1994.