软件的非功能需求及测试方法探讨.doc

软件的非功能需求及测试方法探讨S一软件的非功能需求及测试方法探讨刘海杜(上海亚太计算机信息系统有限公司上海200040)摘要完整的软件需求应包括功能需求和非功能需求.非功能需求在软件系统研发过程中起着重要的作用,它是奠定衡量软件系统是否优劣的标准.本文论述了非功能需求的分类和其在软件架构中的重要性,阐述了非功能性测试的重要步骤,并从内存占用,CPU#率,磁盘空间,网络流量等指标对性能测试的结果进行了探讨,最后还介绍了非功能性测试的常见误区.关键词质量属性;非功能需求(NFR);非功能性测试;性能测试doi:10.3969.issn.16747933.201O.05.005ResearchonNonfunctionalSoftwareRequirementanditsTestingMethodsLlUHaidu(ShanghaiAsia&PacificComputerInformationSystemCo.,Ltd.,Shanghai200040,China)AbstractAcompletesoftwarerequirementshouldincludefunctionalrequirementandnon-functionaIrequirement(NFR).NFRhassignificanteffectonthedevelopmentofsoftwaresystem,whichspecifiescriteriausedtojudgetheopera-tionofasystern.ThispaperdiscussesclassificationofNFRanditsimportanceinsoftwarearchitecture;italsoindicatesthekeystepsinnon-functionaltestinganddiscussesresultsofperformancetestingthroughevaluationofmemoryfootprint,CPUutilization,diskspace,networktrafficandotherindicators;lastly,itintroducessomeofthecommonmistakeshappenedduringnonfunctionaltesting.KeywordsQualityAttributesNonfunctionalRequirement(NFR)NonfunctionalTestingPerformanceTesting0引言软件开发人员通过研发活动和服务来满足客户的客观需求与主观愿望.然而,在一些开发项目中,当软件架构师在识别系统需求和设计整体架构时,往往只关注系统所要实现的功能和采用哪些技术来实现,而轻视甚至忽视了另一个至关重要的问题非功能需求,忽视非功能需求,就如同忽视功能需求一样,将会造成非常严重的后果.例如某大型B2C购物网,以其便利强大的功能在很短时间内使交易额达到上千万,但是由于后台安全性能方面的疏漏,被黑客侵袭,造成开业不久交作者简介:刘海杜,1957年7月生,女,工程师/学士,主要从事及研究领域:信息技术/质量和项目管理,E-mail:liuhaidu126.COrn.罾易资金就大量失窃的巨大损失.软件的非功能需求不仅决定系统的质量,还在很大程度上影响系统的功能需求定义.缺乏良好的非功能性需求识别和定义将给软件架构设计带来负面影响,有时还会淹没一些功能需求给客户带来的价值;而缺乏专业的,全面的非功能性需求测试,也将遗留系统缺陷,甚至导致系统失败.1非功能需求的属性定义在需求调研和分析中,非功能需求(Non-functionalRequirement)描述的是软件系统运行的质量,而不是具体的系统行为.非功能需求是指软件系统为满足客户业务需求(即功能需求)而必须具有的,除功能需求以外的软件系统属性特征,是衡量软件系统是否符合质量S一要求的重要判据.软件系统分为功能需求和非功能需求两种.功能需求是每位软件研发人员都非常熟悉的一类需求,并非本文关注的重点.非功能需求分为质量屙胜和需求约束1】.质量属性是软件系统整体质量品质的体现,往往和大多数功能有关,但又不仅仅表现在某个功能的内部.质量属性在非功能需求方面同样包含众多内容.例如,软件系统的性能,安全性,易用性,可靠性等.需求约束规定了架构设计中必须遵循的制约条件.例如,客观上限制了要采用什么操作系统或数据库,指定采用哪些开发技术,是否需要与遗留的老系统进行互操作等.当然,还包括考虑客户所在行业必须遵守的法律法规,政策方针和行业标准,企业标准等等,需求约束也有可能会衍生出质量属性需求和功能需求.软件需求的提出者基于其所处的职能不同而不同.一般可归纳为三个等级,如图1所示.组织级(项目主要领导和干系人),用户级(软件的最终用户),开发级(设计,开发,维护团队).三个等级均会不同程度影响各个层次的需求.功能需求质量需求约束图1软件需求空间分割图非功能需求与功能需求一样,同样也来自于组织级,用户级和开发级,但是所涉及的内容有所不同.组织级的非功能需求反映了客户组织层面对软件系统高层次和最终的一个目标要求,一般会强调软件系统安全可靠方面的要求,同时还要符合国家相关政策;用户级的非功能需求会更关心系统的易用性和执行速度;而开发级的非功能需求来自开发者和升级维护人员,他们会更重视软件的可扩展性,可重用性,可移植性和易测试性等,因为这些因素都将影响开发和维护成本.另外,作为系统架构师还必须充分考虑客户对上线时间的要求,预算限制,以及集成需要等非功能需求,并特别关注客户所在领域的业务规则和业务约束等,所以作为需求调研团队与系统架构师要全面分析来自这三类中任何一类的需求目标和期望.从软件生命周期的角度,非功能需求又可分为运行期质量属性和开发期质量属性2】.运行期质量属性:?性能(Performance):指软件系统及时提供相应服务的能力,包括速度,容量和持续高速性.系统整体性能的提高是多方面的,必须在各性能指标中寻找平衡点,否则会导致某些环节出现瓶颈.?安全保密性(Security):指系统同时兼顾向合法用户提供服务,又阻止非授权使用的能力.通常的做法是分析威胁原因,制定威胁列表,评估优先级,根据威胁的种类选择相应的安全技术,进行对应的安全设计.在实际应用中,通常选择比较成熟的安全技术.?易用性(Usability):指软件系统易于使用的程度.?可用性(Availability):指系统长时间无故障运行的能力.如医院HlS系统,金融交易系统对软件和硬件有相当高的要求,一般要求达到24小时不问断运行.?可伸缩性(Scalability):指当用户增加时,系统维持高服务质量的能力.例如,当业务量剧增时,可以通过增加服务器等手段来提高性能,而无需对软件系统本身进行修改.?互操作性(Interoperability):指本软件系统与其他系统交换数据和相互调用服务的难易程度.如不同的应用系统,不同的网络和不同的操作系统协同工作并共享信息.?可靠性(Reliability):指系统在一定时间内无故障运行的能力.?健壮性(Robust):也称容错性,指系统在发生异常情况下仍能够正常运行的能力.例如,用户进行了非法性操作,相关联的软硬件发生了故障,以及黑客攻击等非正常情况.开发期的质量属性:?易理解性(Understandabty):指系统设计能够被开发人员理解的难易程度.?可扩展性(Extensibility):有时也称灵活性,指为适应新需求或需求变化,为软件增加新功能的能力.?可重用性(Reusability):重用软件系统或其中一部分能力的难易程度.?可测试性(Testability):对软件进行测试以证明其满足需求规约的难易程度.实际项目中,主要指进行37圈S一单元测试等难易程度.?可维护性(Maintainability):在修改Bug,调整功能,提高适应性等方面进行系统维护时,而进行修改点定位并实施修改的难易程度.?可移植性(Portability):将系统从一个运行环境转移到另一个不同的运行环境的难易程度.对于非功能需求描述的困难在于很难像功能需求那样,可以通过结构化和量化的词语来描述清楚,所以在描述过程中必须强调业务场景,客户,环境等方面的因素.其目的就是要说明非功能需求不是无限度的,任何一项非功能需求的描述和实现往往会付出更大的研发人力成本和硬件网络成本【3】.2非功能需求对架构设计的影响我们都遇见过这样的情形,提供的解决方案虽然合理,功能需求也满足客户的目标,但当碰上特殊情形,如用户数剧增,黑客侵袭等突发事件时,系统就会变得非常脆弱,有时甚至不堪一击.造成这种灾难的原因就是在架构设计中不重视或忽略了系统的非功能需求.非功能需求解决的不是系统实现的具体功能,而是如何使系统在实际环境中更好地运行.在架构设计中非功能需求起着决定性的作用,一个有经验的系统架构师会综合考虑各方面因素,提出适当的非功能需求质量属性和需求约束,并将其体现在软件架构设计中.性能和可伸缩性.如果不考虑如何使用资源(例如处理器,内存和磁盘空间等),系统的功能性,可靠性和可用性再好,最终都有可能导致失败.系统的运行速度,资源利用率,以及其响应时间等性能指标是否达到预定的目标,程序的设计是否合理利用了缓存,是否符合性能要求等等,这些都是性能方面要考虑的问题.如果系统在小范围内运行时看起来速度相当快,那么还应更深入设计当扩展至每秒,每分钟或者每小时成千或上万个活动,是否达到客户认可甚至超过客户期望的吞吐量目标.至于通过复制系统来实现应用的线性扩展,以及系统是否存在瓶颈,这些都是可伸缩性方面要考虑的问题.安全保密性.如何让使用者只能访问经过授权的功能,如何考虑来自网络的攻击,机器攻击,甚至来自从自己系统内部的漏洞攻击,都是软件架构中必须重点思圈38考的问题.可靠性.应设计即便硬件出现一些故障,系统还能可靠运行的方案.还要制定复制和故障转移方案,例如,是选择手动干预,还是系统自动进行故障转移.当然还要考虑实现可靠性是否会对性能造成负面影响,实现可靠性的成本有多高等问题.易用性.除了考虑操作便捷,使用方便外,还要考虑软件系统是否会给客户带来不适当的负担.如果系统是根据模型.视图.控制器(ModelView-Controller)体系结构来设计,那么要在多客户界面设计中对这些问题进行综合思考.可维护性.如果开发人员,管理人员,操作人员和维护人员不能够解决如何管理应用程序的问题,那么软件系统有可能在首次发布后不久就夭折.作为一名有经验的系统架构师,必须为管理人员和维护人员设计如何担负维护任务的方法.包括如何配置系统,如何监视系统,如何解决需要重复执行的任务(例如,安装许多应用程序),除此之外还要考虑可复制的部署流程等等.可移植性.设计标准来提供某种形式的平台中立性,这类问题同样牵涉到基于开放源代码的移植.如果不考虑这样的问题,那么我们的软件系统则不是一个对客户和开发人员友好的系统.一般来讲,系统架构师特别需要考虑如何支持应用程序迁移到高版本的应用服务器上,如何应对供应商撤消对该版本的支持等一系列系统可移植性问题.综上所述,非功能需求在软件系统架构的设计和制定过程中具有客观的影响力,它是架构设计中不可忽视的重点和难点.3非功能性的测试非功能需求的属性,很大程度需要通过测试来验证其设计的合理性.比如像系统性能,牵涉面非常广,又比如像可用性和可维护性这样的需求,主观因素可能会占主导地位.另外一些情况,如可伸缩性和性能方面,在测试中如何进行模拟成为一个挑战.所以如何确保非功能需求的落实,成为了至关重要的确认过程.下面从软件测试生命周期的阶段着手,分析非功能性测试的要点.3.1制定测试计划非功能需求一旦确定,就应合理安排测试计划和资S一源需求.这是非常关键的一步,因为即使在同一个软件系统中,大多数非功能性测试与功能性测试也是完全不同的,在测试计划阶段就特别需要为例如特殊环境建立,测试工具准备等事宜制定计划安排.以制定性能测试计划为例,需关注以下几项主要内容:(1)分析应用程序首先要分析应用程序的软硬件以及服务器和客户机的配置,预计系统可承载的客户访问量,通信方式,通信装置(网卡,路由器等)的吞吐量,每个通信装置能够处理多少并发用数.其次还要分析系统的使用方法,确定哪些功能需要优先测试,什么角色使用该系统以及每个角色会有多少用户,每个角色的地理分布情况等,从而预测负载的最高峰出现的时机等.(2)确定测试目标虽然非功能性测试相对于功能性测试所需要的测试用例在数量显着减少,但是它所需要付出的努力却是相当大的.在分析应用程序的基础上,细化测试策略和目标.在性能和负载测试中通常需要采用自动化和特殊的测试工具,有时,配置测试和负载测试会需要启动特殊的必要条件,这些都必须在测试计划中被确定.同时还要确定可用性测试的目标.另外,支持非功能性测试的设备和环境等也要明确下来.实施可用性,安全性等测试所需的软件,以及根据约束条件和各非功能性测试的特点,合理安排测试时间和测试资源等.3.2开发测试脚本有些非功能性测试,如性能测试,压力测试等通常不可能由手动来完成,需要编制自动操作脚本,或选购测试工具,或编写临时开发工具.在很多情况下,非功能性测试脚本是实施功能性测试所需脚本的一个扩展.对于为负载测试以及测量启动时间所需要的工具或脚本也应在该阶段开发.编写测试脚本要设置测量点,同时也要测算系统应该承受的最大虚拟用户数,或是测试系统可以承载的最大虚拟用户数【4】.3.3分析测试结果测试结果的分析是一个复杂的过程,通常可以从并发数,平均事务响应时间,每秒点击数,业务成功率等多个方面进行分析.下面以性能测试为例,主要从内存,CPU,磁盘,网络等关键参数进行探讨:(1)辨识内存泄漏现象内存是第一个需要监视的对象,确定系统瓶颈的第一个步骤就是要排除内存问题.内存问题主要是检查应用程序是否存在内存泄漏.内存泄漏问题经常出现在由于设计等原因导致部分内存没有释放,而将内存慢慢耗尽.要判断内存泄漏问题,需要一个较长的时间,要检测,研究和分析当内存耗尽时,应用程序的各个指标的情况.如果发生内存泄漏,ProcessPrivateBytes(指某个处理不能与其他处理共享已分配的当前字节数)和ProcessWorkyingSet的值往往会升高,同时Avaiablebytes的值会降低.(2)辨识CPU瓶颈现象ProcessorQueueLength表示处理器列队的线程数,一般少于2个.Processor%Processortime表示处理器的利用率,一般小于75%.如果ProcessorQueueLength显示的队列长度一直大于或等于2不变,并且Processor%Processortime平均值大于95%,或是网卡和磁盘的值比较低,那么表示此测试的负载对于目前的硬件过于沉重,可以确定存在CPU瓶颈问题.此时的CPU已经不能满足程序需要,需考虑扩展CPU.如果发现ProcessorQueueLength,示的队列长度超过2,而Processor%Processortime却始终保持低的值,则可以判定这时处理器一般没有瓶颈问题,而应考虑是否有处理器阻塞的情况.(3)辨识应用程序存在的问题如果系统由于应用程序代码效率低下或者系统结构设计存在缺陷,就可能会导致大量的上下文切换,这时ContextSwitches/sec显示的上下文切换次数会比较大.如果系统的吞吐量降低,并且CPU的使用率很高,而此时若出现切换水平在15000以上,那么就意味着上下文切换次数过高,这表明应用程序占用了过量的系统资源.同时还可以比较C0ntextSWitches/sec和%PrivilegedTime来判断上下文切换是否过量.如果%PrivilegedTime的值超过40%,且上下文切换的速率也很高,那么应该检查为什么会产生这样高的上下文切换.(4)辨别网络连接速度瓶颈现象BytesTotallsec表示发送和接收字节的速率,包括帧字符在内.判断网络连接速度是否是瓶颈,可以用39圈SBytesTotal/sec的值和目前网络的带宽比较.如果该BytesTotal/sec的值和目前网络的带宽相除,结果小于50%,说明网络连接不存在瓶颈.图2显示了场景运行期间每秒从WebServer上接受到的数据值.用这个值和网络带宽比较,可以确定目前的网络带宽是否是瓶颈.如果用户数增加,曲线没有随着增加,而是呈比较平的直线,说明网速不能够满足系统流量.图2网络带宽分析图(5)辨识磁盘瓶颈现象判断磁盘瓶颈的方法可以通过以下公式来计算:每磁盘的I/O数=【读次数+(4写次数)】/磁盘个数如果计算出的每磁盘的I/O数大于磁盘的处理能力,那么磁盘存在瓶颈.读写磁盘的时间Avg.Disksec/Transfer-般要求为0.03秒或更低,磁盘的QueueLength经验值是2,如果大于2,则表明不能满足磁盘I/O的要求【5】.图3提供的数据,可以把瓶颈定位到特定机器的某个部件.圈图3系统资源分析图4非功能性测试常见的问题在现实开发中,尽管非功能性测试以其在测试中独特的地位越来越受到系统架构师,测试人员,开发人员和客户的重视,但是不管是测试人员还是开发人员,仍然在认识上存在种种误解.40误解一,提高硬件设备的配置一定可以提高软件系统的性能.其实提高硬件配置只解决了系统性能的最基本条件,因为如果软件系统自身存在非功能性问题,再多的资源可能也不够用,比如内存泄漏问题,并发用户数等问题,随着时间的推移,内存终究会被耗尽,最终导致系统崩溃.因此,如果客户对软件的性能要求较高,就意味着除了考虑提高硬件配置外,还要从操作系统,WebServer,数据库配置等方面着手提高性能,同时也要在开发的软件系统本身进行优化,以全面提高系统的性能.误解二,非功能性测试独立于功能测试.而事实上功能测试可以发现非功能问题,非功能测试也能发现功能问题.非功能测试和功能测试是紧密联系在一起的,因为很多非功能测试发现的问题是由软件自身功能缺陷引起的.如果应用系统功能不完善或者代码运行效率低下,通常会带来一些性能问题.功能测试通常要先于非功能测试执行或者同步进行,软件功能完善可以保证性能测试进行得更加顺利.误解三,有人说系统存在瓶颈,就不可以继续使用,而要彻底解决问题后才可使用.非功能性测试中发现瓶颈的目的主要是为了掌握系统特性,为改善和扩展系统提供依据.因此要分析瓶颈会对系统造成多大的影响,性能方面给系统留有30%左右的扩展空间就可以了,一些所谓的瓶颈可以不必去理会.例如,5000个用户并发时发现了系统瓶颈,而客户的最大并发用户数量在2500左右,这样的性能问题完全没有必要处理,要是2800或者3000个并发用户出现性能问题就应该认真地调整系统性能了.误解四,很多时候,测试人员只在开发环境下进行非功能性测试.实际上大多数的开发环境硬件条件比较牵强,所以不能很全面地反映非功能需求存在的问题.因此非功能性测试要尽量在高配置的客户正式环境下进行.但是如果是为了发现某些功能方面的问题,例如为了发现并发算法的一些缺陷,在开发环境上测试也无妨.误解五,在非功能性测试中要做到穷举测试.这个问题一般也会困扰测试人员.事实上,与程序中存在的错误概率一样,即一段程序中存在的错误概率与在这段程序中发现的错误数呈正比.这种Pareto原理同样也可用于非功能性测试,即非功能性测试中发现的80%的错S一误中可能集中在20%的程序模块中.在非功能性测试中不可能覆盖每一个部分,这也意味着有性能问题的模块可能被忽略掉,我们在设计非功能性测试方案时,需要采取一些策略和技巧,尽量做到用尽可能少的测试,发现尽可能多的Bug6.5结论本文阐述了非功能需求和测试的一些指导思想,重要性和相关方法.一个功能正确的软件,如果不能满足客户的诸如性能,可靠性之类的非功能性需求,则很可能会产生劣质价值,甚至会导致系统崩溃的后果.而一份得到客户认可的非功能需求报告,很大程度上需要依靠测试来保证其设计的合理性.非功能性测试能够在已存在的测试流程的框架中实施,但要特别注意测试时间节点,还要避免一些可能被忽视的误区.参考文献1RogerS.Pressman.SoftwareEngineering-APractitionerSApproachZ.McGrawHill,2006.2】2KarlE.Wiegers.软件需求【M】.北京:清华大学出版社,2004.【3】温昱.软件架构设计【M.北京:电子工业出版社,2007.5.4】Kazman,R.,Abowd,G.,Bass,L.,andC