当前位置:文档之家› 软件测试之项目风险分析的基本概念

软件测试之项目风险分析的基本概念

由安博测试空间技术中心https://www.doczj.com/doc/71172691.html,/提供

1、引言

由于软件项目的研制需要开发新的技术,或使用许多已经过验证的技术和产品,但产品生产数目一般较少,这些技术和加工工艺不容易达到成熟或定型的程度。且大型项目的研制需要长时间大规模的组织、指挥协调工作,以及漫长的研制周期等,都会带来种种难以预见的不确定性因素。这些不确定因素的存在使得软件项目能否按照预定的计划--费用、进度和性能完成研制任务往往难以预料,不可能做到研制完全成功,存在着失败的风险。所以在项目研制的可行性分析和方案认证时,加强方案风险分析是十分必要的。

对风险的研究自七十年代末开始,其应用的风险分析方法与可靠性分析方法类似,或在此基础上进行扩充。目前,在风险研究方面,比较著名的方法有GERT(图解评审技术),VERT(风险评审技术),RSINET(风险信息系统与网络评审技术)和SLAM(多功能构模仿真语言)等。GERT的基本特点是可以直接对网络模型进行计算机仿真分析,其模型元素与相应的分析程序相配合,可以用来描述复杂的排队系统、项目管理及生产线方面的问题,应用十分简便、灵活,而对时间、费用、性能方面的问题不太适合;SLAM是一种以FORTRAN为基础的构模仿真语言,可进行离散网络、连续系统及离散事件的综合仿真,能适应多种构模需要,但提供资源模块有限,仿真不能进行全过程支持,不能支持图形建模等不足;VERT 可处理时间、费用、性能等关键性风险参数,能对多目标优化,具有较大的实用价值。在这些风险方法中,VERT对于时间、费用和性能三个指标在处理水平上平等对待,既可独立地进行并行处理,也可通过数学关系式而相互联系起来进行处理;节点的逻辑功能丰富,活动上的三项指标都可用一定的概率分布、直方图或数学关系式来描述,因而VERT网络模型比较接近实际系统的要求;VERT对于费用和性能这二项指标,可按用户的需要灵活地加以应用。

2、风险分析的概念

风险的定义是:对目前所采取的行动,在未来没有达到预期结果(失败)的可能性。其大小可用失败的概率和失败的后果两个变量来标识。

风险分析有狭义和广义两种,狭义的风险分析是指通过定量分析的方法给出完成任务所需的费用、进度、性能三个随机变量的可实现值的概率分布。而广义的风险分析则是一种识别和测算风险,开发、选择和管理方案来解决这些风险的有组织的手段。它包括风险识别、风险评估和风险管理三方面的内容。本文中论及风险分析时,都采用后一种定义。

风险识别是指确定哪些可能导致费用超支、进度推迟或性能降低的潜在问题,并定性分析其后果。在这一步须作的工作是分析系统的技术薄弱环节及不确定性较大之处,得出系统的风险源,并将这些风险源组合成一格式文件供以后的分析参考。它属于定性分析的范围。风险评估是指对潜在问题可能导致的风险及其后果实行量化,并确定其严重程度。这其中可能牵涉到多种模型的综合应用,最后得到系统风险的综合印象。而风险管理则是指在风险识别及风险分析的基础上采取各种措施来减小风险及对风险实施监控。这也可以说是风险分析的最终目的。

作为对风险概念的进一步界定,本文将简单介绍风险中的两种不同类型及风险分析与可靠性分析的区别。

2.1、系统运行及项目研制风险

第一类风险是系统运行风险。指当一部分系统运行时,由于种种不确定性因素或系统本身硬件或组元的失效而造成预定任务的完成不确定性以及由此而带来的系统设备的损坏或人员的伤亡。这类风险由于其明显的危害性及影响性,目前进行研究得较多,有代表性的如大型航天软件的运行风险管理。已经发展成熟的分析方法有如FMECA(失效模式与效应分析)、FTA(故障树分析)、ETA(事件树分析)及事件树/故障树分析量化基础上的PRA(风险概率评估)和DPRA(动态概率风险评估)等。

第二类风险是项目研制风险,这也是本文的主要研究范围。它是指大型项目研制开发过程中,由于技术的难以保证、管理的不得力及经费的拖延导致研制出的系统性能降低、费用超标、进度延迟等。这类风险由于其危害呈隐性,目前进行研究得较少。项目研制风险一般包括技术风险、进度风险及费用风险。

两类风险的不同之处在于,对于系统运行风险,系统已经存在,因对其分析必须从单个硬件或主元的失效及其综合影响上考虑。而作为项目研制风险,由于并无一确定的系统,系统研制成功本身便是研制任务的状态之一,这决定了它的分析方法与上述不同,不能针对硬件分析,而须从事件的角度上进行考察。两类风险的另一个不同之处在于项目风险的非刚性。所谓非刚性是指当风险源导致风险发生以后,造成的后果可以修复。

2.2、系统运行风险与可靠性

系统运行风险与可靠性分析是两个极易混淆的概念,它们都是指对于某种工艺过程或设备的失效或运行状态的研究。但其分析的目的却有所不同,有必要在此作一简单的区分。

可靠性的定义是系统在一定时间内能够完成规定任务的概率。其研究的范畴在于系统硬件或组元的耐用程度,研究的最后结果是系统整体失效随时间而变化的可能性。而系统运行风险则是研究这种失败可能对社会造成的危害,其最后结果是造成的系统设备损坏的或人员伤亡的期望值。

3、风险种类

对软件项目的管理部门来说,在做出与规定费用按规定时间交付规定产品或达到规定性能水平的决断时,风险是永远存在的。软件项目管理部门因风险而导致工作失败有三种方式:产品达不到规定的性能水平、实际费用过高、交付过迟等。就一个项目而言,其面临的风险可分为五个方面:技术(与性能有关)、保障性(与性能有关)、计划(与环境有关)、费用和进度。

3.1、技术风险

技术风险可以定义为发展某项新设计所包含的风险,发展这项设计的目的是要将性能水平在原有基础上提高一步,但也可能因为受到某些新的约束条件的作用而使性能水平原封未动,甚至反而有所下降。技术风险的性质和原因随军用系统的设计而各不相同。许多技术风险往往是由于对新系统和新设备提出前所未有的性能要求造成的。

3.2、计划风险

计划风险是包括获取和使用一些可能不受软件项目控制但又可能影响软件项目方向的可用资源和活动。计划风险一般不会与改善技术水平有直接关系。计划风险可按一些因素的性质和来源分类,这些因素有可能中断软件项目实施计划。造成软件中断的因素主要以下几种:(1)与软件项目直接有关的高层权力机构决策造成的中断;(2)一些影响软件项目的事件或行动造成的中断;(3)主要由于一些不能预见的与生产有关的问题造成的中断;(4)因能力不足造成的中断。

3.3、保障性风险

保障性风险是与系统的部署和维修有关的风险,这些系统指目前正在研制或正在部署的系统。保障性风险包含有技术和计划两个方面风险的特征。构成综合后勤保障要素潜在的十种风险源要素是:(1)维修规划;(2)人力和人员;(3)保障设备;(4)技术资料;(5)训练;(6)训练保障;(7)计算机资料保障;(8)设施;(9)包装、装卸、存储和运输;(10)设计接口。

3.4、费用和进度风险

一些性能和设计技术问题有时要靠增加费用和延长进度来解决,这往往会使问题变得复杂化。费用和进度增长指预计软件项目费用和进度与实际费用和时间之间的差异。因此,费用和进度增长会造成两个主要的费用/进度风险区:预计时定下不合理的低费用/进度目标所造成的风险;要想满足合理的费用/进度目标,软件项目就必须给定一个谨慎的风险。

4、风险分析的步骤

风险分析试图定量回答一些问题,这些问题与为了完成某个特定任务所研制的软件和硬件性能上固有的效果范围有关,也与人们自身相互因素的作用和影响有关。风险分析人员确定风险的方法是:把不希望的事件发生的概率与每个可预见的后果的大小相结合。

一般地,系统运行风险分析可以分为以下四个步骤:(1) 风险识别、检测某种情况,确定潜在的风险范围;(2) 风险量化,确定事件发生的概率以及产生的后果;(3) 风险影响评估和方案选择,定量计算发生风险的后果和选择行动方案;(4) 风险处理计划,描述处理风险的各种方法,并推荐具体的处理风险的行动。项目风险分析步骤也可以这些步骤为参考。

5、风险分析的方法

我们知道,对于风险分析所作的工作大多局限于任务风险分析当中。这些方法对于考虑项目风险领域的分析方法也有一定意义,风险分析方法可分为定性和定量两种,定量的风险分析方法是在定性的基础上而实现的。下面,我们对这两类风险分析方法作简要的论述。

5.1、定性风险分析方法

定性风险分析的目的是界定风险源,并初步判明风险的严重程度,以给出系统风险的综合印象,表1是一些定性风险分析方法的简介。易于看出,初步危险分析是用于识别系统中可能存在的风险源,而以下的几种方法则用于定性地量化各种风险源可能对系统造成的破坏,从而判明系统风险大小。

5.2、定量风险分析方法

定量风险分析是在定性分析的逻辑基础上,给出各个风险源的风险量化指标及其发生概率,再通过一定的方法合成,得到系统风险的量化值。它是基于定性风险分析基础上的数学处理过程。现发展较为成熟的方法有PRA(概率风险评估),DPRA(动态风险概率评估)及仿真通用软件VERT(风险评审技术)等。

PRA和DPRA都是在FTA分析基础上的量化,在可靠性及运行系统风险分析领域内应用广泛。稍作改造,我们便可将其运用到项目风险分析领域。其分析步骤如下:(1)识别项目研制过程中的困难环节,找出风险源;(2)对各风险源考察其在项目研制中的地位,及相互逻辑关系,给出项目的风险源树;(3)标识各风险源后果大小,及风险概率;(4)对风险源通过逻辑及数学方法进行组合,最后得到系统风险的度量。如果是用DPRA进行评估,则尚须考虑它们在时间上的关系。

另一种被广泛运用于风险评估的方法是VERT 。VERT是国外在八十年代初期发展的一通用仿真软件,它对项目研制构造过程网络,将各种复杂的逻辑关系抽象为时间、费用、性能的三元组的变化。网络模型面向决策,统筹处理时间、费用、性能等风险关键性参数,有效地解决多目标最优化问题,具有较大的实用价值。它的原理是通过丰富的节点逻辑功能,控制一定的时间流、费用流和性能流流向相应的活动。每次仿真运行,通过蒙特卡洛模拟,这些参数流在网络中按概率随机流向不同的部分,经历不同的活动而产生不同的变化,最后至某一终止状态。用户多次仿真后,通过节点收集到的各参数了解系统情况以辅助决策。如果网络结构合理,逻辑关系及数学关系正确,且数据准确,我们可以较好地模拟实际系统研制时间、费用及性能的分布,从而知道系统研制的风险。

6、风险分析的原则

在风险分析时,应该遵循一些分析原则。下面是进行风险分析的几个一般性原则:

(1)风险分析是软件设计的一部分,就像应力分析是传统软件设计实践的部分一样;

(2)风险分析是正式的、严谨的、定量化的;

(3)风险分析的目的是为了支持决策,应当把风险分析作为系统软件设计和研制过程的一部分,而不应该过迟而无法做出主要的改变和资金的压力强迫在安全性和可靠性上妥协,而这种妥协不能接受的情况下,作为一种反省进行;

(4)风险分析可以按各种等级的详细程度、彻底程度和精密程度来进行;

(5)风险分析详细、彻底、精确程度与分析项目的重要性和环境潜在的破坏程度大小相一致;

(6)在一个项目的早期概念阶段,能够而且应该实施近似的风险分析,随着设计的逐渐开展,风险分析的精度和详细程度也随之提高。

性能测试的门槛软件测试

随着软件测试行业的逐渐发展,性能测试也变得火热起来。从各大测试论坛和测试交流群的交流主题的热门程度来看,性能测试已经成为大家非常感兴趣的话题。性能测试作为软件测试行业技术性相对较高的工作(自动化测试、白盒测试、性能测试)来说,个人觉得其操作门槛还是不低的。对于测试新手来说入门有一定的难度,做的好就更加不容易了,可能花了不少时间而实际收获不大。因此觉得有必要来专门探讨一下性能测试的门槛,以及如何更好的迈进这个门槛。

先来分析一下一些关于性能测试入门级的常见问题:

1、请问怎么做象PhotoShop这类单机程序的性能测试;

2、用Delphi开发的程序,应该用什么协议来录制脚本;

3、用IP欺骗能对外网进行测试吗;

关于第1个问题,问题本身并没有错误,单机版也有性能问题。但和我们通常所说的性能测试是两回事,不能混为一谈。如果这个算是问题的话,那我想是由于不清楚性能测试的概念和原理所造成的。第2个问题也不少见,但这种问题无法回答。我们知道,性能测试采用的协议是由被测系统的体系架构和通信协议决定的,而不在乎你用什么开发工具或开发语言。第3个问题,关于IP欺骗一般只用在内网,不管你在内网如何欺骗,经过网络地址转换后到了外网上的IP地址表现就是你的公网的IP,除非你一开始就设置成公网的IP地址,但这个一般都不可能。这个问题体现提问者对于网络知识的理解还不深入。

以上问题反映了在学习性能测试人员的一个比较普遍的现象,缺乏必要的知识积累、知识面不足,但又由于学习兴趣或工作压力期望急于求成,由此而形成这样一个矛盾的局面。

在我看来,性能测试是一项综合性很强的工作,甚至可以作为一项工程来看待。

从性能测试的知识体系来看,性能测试需要掌握性能测试的基础知识、业务知识、开发相关知识、以及性能测试工具。

基础知识包括性能测试的原理、常见的测试类型、方法、策略,如何进行一个计划、设计、实施、分析等性能测试过程。没有性能测试基础知识,一切简单的性能测试在你手上都将出现各种问题,测试交流将变得难以沟通,同时性能测试的成功率将大大降低。

业务知识通常都被忽略了。性能测试要基于被测系统的应用场景才有实际的价值,测试场景对性能测试结果有决定性的影响,因此测试场景的设计是非常关键的,场景的设计需要和业务应用结合起来。在一些比较正规的性能测试过程中,会有业务人员配合一起做性能用例设计的。

开发相关的知识也是必须具备的知识,通常在这方面也是我们最大的缺点。这方面的知识包括操作系统、数据库、应用服务器、中间件、网络等,每一个都是一门很深的学问,而要求性能测试人员都精通好像也不太现实。但起码的知识还是需要掌握的,比如通常有哪些参数需要监控和调整,它们之间是如何通信和运作的,某一方面知识的欠缺都可能导致测试模拟不准确或问题定位不充分,没有这些知识的支撑性能测试将变得难以下手或者学习工作的进展都会有很大的影响。

测试工具的应用,这个是目前学习的焦点。只有在前面3点的基础上,采用合适的测试工具,才有助于测试目标的达成。

从另外的角度分析,性能测试又可以分为技术、方法和管理方面的范畴。没有方法的指导光有技术那是行不通的,那是有勇无谋的体现。同时性能测试经常作为一个独立的阶段和活动,更需要用项目管理的方法进行,比如一个在客户现场的性能测试验收测试,与客户进行交流、时间计划的制定、测试进度的控制、测试脚本和测试数据的版本管理、各种资源的谐调等,都是需要用管理的思想进行的。

从以上分析可以看出,由于性能测试工作需要具备这么多的知识,因此在一定程度上也成为了性能测试的门槛。这个综合的门槛将会成为很多性能测试新手入门的一道障碍,要突破这道障碍,建议结合自己的知识体系有针对性地去学习和提高。

性能测试是一个技术与方法并重的工作,目前论坛上多谈技术,少谈方法,很多人甚至在没有任何性能测试基础知识的情况下就埋头苦学测试工具,我觉得是不应该的。我们应该意识到,测试工具只是性能测试中的一部分,仅是为达到性能测试目的而采用的一种手段。性能测试对于我们最大的价值在于方法和经验,我们学习的目标是整个性能测试过程上方法学的东西,而不是掌握具体某个测试工具。LoadRunner并不是万能的,在什么情况下应该采用什么工具才能达到最佳的效果,需要我们去判断。

另外,学习需要有一个循序渐进的过程,性能测试需要长时间的知识积累,没有什么捷径可言。从学习效率和职业发展方面考虑,本人不太建议没有工作经验的测试新手一上来就扎进性能测试之中去,这样将花费你更多的时间精力去学习,是一种事倍功半的效果。

相关主题
文本预览
相关文档 最新文档