软件测试引论概要Word下载.docx
- 文档编号:370479
- 上传时间:2023-04-28
- 格式:DOCX
- 页数:20
- 大小:34.24KB
软件测试引论概要Word下载.docx
《软件测试引论概要Word下载.docx》由会员分享,可在线阅读,更多相关《软件测试引论概要Word下载.docx(20页珍藏版)》请在冰点文库上搜索。
因此,产品的提供和使用可构成服务提供的一部分。
服务可以与产品的制造和提供相关联。
当然,服务亦需投入资源和活动,也是一种
软件测试实用指南
2
价值的增值。
影响质量的因素是什么?
其包括5大因素:
人、材料、设备、方法和环境。
显而易见,人的因素第一,有了人的主动性、对质量的深刻认识,就会非常重视质量的各个环节;
材料也非常重要,半导体的收音机和集成电路的收音机取材不同,质量也就有天壤之别;
设备的先进程度和工作状态的好坏也能够深刻影响产品质量;
方法包含内容更广泛,它可以是生产方法、设计方法、管理方法、检验方法,这就是技术因素;
环境也非常重要,集成电路的生产就与环境密切相关,如尘埃就能决定集成电路块是否报废。
任何一个机构,都必须确定质量目标,质量目标就是产品和工程质量在一定时间内可达到的水平,产品和工程质量目标的制订需做3个方面的调查。
(1用户对开发新产品或改进老产品的意见和要求,包括产品性能、可靠性、安全性、价格、使用维修、外观包装和运输储存等。
(2生产过程中老产品曾经出现过的问题及新产品开发中可能发生的问题。
(3国内外有关的技术与经济情况。
制定质量目标还需考虑成本的增加。
任何一个产品或者工程项目,其价格是由销售成本所决定的,销售成本包括生产成本、质量成本和利润。
就质量成本而言,包括损失成本、检验成本和预防成本。
损失成本是因产品未能达到质量要求而造成的各项损失费用,一般包括内部损失(如报废、返修、降级等和外部损失(如拒收、索赔、声誉破坏等;
检验成本是用于检验产品质量所需的各项费用;
预防成本是用于预防产生不良产品所需的各项费用,如员工培训、质量管理开销、检测设备购置等。
现在人们不仅从技术层面上去思考产品质量,也从质量管理的角度去思考产品的质量保证,ISO9000、CMM等都可以看作质量管理所引发的对机构在质量保证方面的考核。
所谓质量管理就是为保证和提高产品或工程质量所进行的调查、计划、组织、协调、控制、检查、处理及信息反馈等各项活动的总和。
按照国际标准化组织的定义,则包括确定质量方针、目标和职责,并在质量体系中通过例如质量策划、质量控制、质量保证和质量改进,使其实施全部管理职能的所有活动。
质量体系是为实施质量管理所需的组织结构、程序、过程和资源;
质量策划是确定质量以及采用质量体系要素的目标和要求的活动,包括产品策划、管理和作业策划,以及质量计划的编制和质量改进的准备工作;
质量控制是为达到质量要求所采取的作业技术和活动;
质量保证是为了提供足够的信任表明实体能满足质量要求,而在质量体系中实施并根据需要进行证实的全部有计划有系统的活动;
质量改进是为向本机构及其顾客提供更多的收益,在整个机构内所采取的旨在提高活动和过程的效益和效率的各种措施。
有关这些概念的认识,读者可以参考清华大学出版社于1999年出版的《软件企业ISO9000质量体系的建立和认证》一书。
第1章软件测试引论3
1.2软件产品和其他产品的差异
1.1节中所讲的产品包括4种类别,其中的软件还不是单指计算机软件,其范围亦大得多。
自从1968年提出软件工程这一概念以来,就希望能够借助传统的工程方法来研发出软件产品。
因此,软件产品在某些方面的确相似于其他工程中的有形产品,但毕竟不相同,它们之间存在一些重要的差别。
所以,在软件工程中,人们认识到不能够简单地把一般工程中的知识、方法和技术直接应用到软件工程上来。
那么软件产品和其他产品有什么不同呢?
(1软件是逻辑产品而不是实物产品。
可以粗略地说软件不是有形产品,磁盘、集成电路块只是软件的载体。
这一事实就意味着费用集中在研制开发上而不在生产上。
当然,由于是逻辑产品,软件就不会用坏、磨损、老化,而且可以不断地改进、优化,其可靠性由逻辑确定。
开发软件在许多方面更像进行数学证明,可是软件产品的评价却主要决定于它们在问题求解中是否有用,而不是决定于抽象的正确性判定标准。
换句话说,开发软件产品时主要使用的是工程标准,而不是数学标准。
(2由于软件是逻辑产品,使得它的功能只能依赖于硬件和软件的运行环境,以及人们对它的操作,才能得以体现。
没有计算机相关硬件的支持,软件难有实用价值。
同样,没有软件支持的计算机硬件,也只是毫无使用价值的机器。
软件与硬件的密切相关的程度是一般工程所没有的。
(3对软件产品的要求比一般有形产品要复杂。
其一,软件产品要完成的多种多样功能,用户难以清晰、准确地表达。
凭此一项,软件系统的复杂性可以比得上历史上任何一个工程项目:
即使保守估计,一个100万条汇编语句的软件,至少有1万个分功能,其中每一个分功能至少可以用两种不同方式制定。
所以,在功能上,软件设计者也得要从210000(相当于103000种功能组合中进行挑选。
其二,对软件产品的要求,如可靠性、易移植性、易使用性等是隐含的,也是难以表达的,而且也缺少度量的具体标准,和有形产品的质量检验的精度相距甚远。
其三,软件设计不仅涉及到技术复杂性,也涉及到管理复杂性。
美国Hetgel曾讲过,当他负责一个软件研制小组时,认为关键的问题是方法学问题;
当他负责50人的软件开发项目组时,逐渐理解到除方法学之外,程序文档变得越来越重要了;
后来他又领导200人的软件开发项目组时,他的认识又有了变化,认识到最关键的问题是管理问题。
这是很有代表性的认知过程。
即使在今天软件工程已有很大进展的情况下,许多人都不愿意去领导一个庞大的项目组。
能像其他工程项目那样进行规模化生产并非易事。
(4在软件设计时发生的复杂性,引起的软件特征包括4方面。
其一,功能的多样性。
软件提供的功能比一般工程产品提供的功能更加多种多样,以致用户一时难以掌握。
为此,
4
使用软件产品,往往还会伴随一个培训任务,而且软件产品的用户手册还不一定能全面描述其功能。
其二,实现的多样性。
对软件产品的要求不仅仅包括功能和性能要求,还必须包括在符合功能和性能要求的各种实现中作出选择,更有实现算法上的优化带来的不同,所以实现上的差异会带来使用上的差异。
其三,能见度低。
要看到软件进度比看到有形产品的进度难得多,这里涉及到如何使用文档(document表示的概念能见度,这又为软件管理复杂性增加难度。
其四,软件结构的合理性差。
结构不合理使软件管理复杂性随着软件规模增大而呈指数增长,换句话说,软件规模的增长所引起的管理复杂性成了设计的难题。
总之,前两方面属于技术复杂性。
后两方面属于管理复杂性。
为了控制软件复杂性,人们进行了各种研究,这在一般工程中是前所未有的。
(5任何一种工程,在其年轻时代总是人工密集的,而到其成熟时期却成为资金密集的。
但是软件工程却也有它自己的特点,尽管今后可能有许多活动可以自动化,而软件的资金密集程度终究会比其他工程学科中的资金密集程度高,其中包含更多的人的成分,可以说软件工程是智力密集型。
从而,它的知识产权保护就显得极为重要,软件本身会越来越值钱,逐步体现出它应有的价值。
1.3软件质量
1.2节讨论了软件产品与其他产品的差异,那么软件产品质量与其他产品的质量有没有区别呢?
先来看软件质量的定义:
反映软件系统或软件产品满足明确或隐含需求的能力有关的特性总和。
其含义有四:
其一,能满足给定需要的性质和特性的全体;
其二,具有所期望的各种属性的组合程度;
其三,顾客和用户觉得能满足其综合期望的程度;
其四,确定软件在使用中将满足顾客预期要求的程度。
简言之,软件质量是软件一些特性的组合,它依赖软件的本身。
对于软件质量有多种不同的视面。
用户主要感兴趣的是如何使用软件、软件性能和使用软件的效用,特别是在指定的使用环境(context下获得与有效性、生产率、安全性和满意度有关的规定目标的能力,即使用质量。
开发者负责生产出满足质量要求的软件,所以他们对中间制品和最终产品的质量都感兴趣,当然开发者视面也要体现软件维护者所需要的质量特性。
对于管理者也许更注重总的质量而不是某一特性,必须从管理准则,如在进度拖延或成本超支与质量提高之间进行权衡,以达到用有限的人力、成本和时间使软件质量达到优化的目的。
保证软件质量基本上可用两种途径来实现,一种是保证生存周期过程,另一种是评价软件
第1章软件测试引论5
最终产品的质量。
这两种途径都很重要,且都要求有一系统来管理质量,该系统应确定管理对质量的保证,指明其策略以及恰当的详细执行步骤。
前者是采用ISO9001质量体系——设计、开发、生产、安装和服务的质量保证模式,或者CMM——能力成熟度模型,或者ISO15504软件过程评估(也称为SPICE,即软件过程改进和能力确定等方法来取得满足质量要求的软件。
后者是把软件产品评价看作软件生存周期的一个过程,目标就是让软件产品在指定的使用环境下具有所需的效用,可以通过测量内部属性,也可以通过测量外部属性,或者通过测量使用质量属性来评价。
软件质量管理经济地实现符合用户要求的软件质量或服务的方法体系及其一系列活动,具体包括确定质量方针和目标、确定岗位职责和权限、建立质量体系(如质量策划、质量控制、质量保证和质量改进并使之有效运行等所有活动。
任何一个机构,要想使自己提供给用户的产品达到并保持一定的质量水平,都必须进行严格的质量管理。
对于一个软件机构来说,也必须建立质量管理体系。
目前能被大家接受和公认的是基于软件生存周期过程的质量管理,包括ISO9001、CMM、ISO15504等都是属于这种类型,如能力成熟度模型(CMM较全面地描述和分析软件机构的软件过程能力的发展程度,建立了一个描述软件机构的软件过程成熟度的分级标准和框架。
软件过程能力是描述遵循一个软件过程而得到期望结果的程度,软件过程成熟度是指一个具体的软件过程被明确定义、管理、控制其实效的程度。
利用能力成熟度模型,软件机构可以评估自己当前的过程成熟度,并通过提出更严格的软件质量标准和过程改进,来选择自己的改进策略,以达到更高一级的成熟程度。
软件产品评价需要策划和管理,从而也是管理职能中的一个部分。
软件质量模型一个框架,它规定了内部和外部质量的质量模型与使用质量的质量模型,以及它们在软件生存周期中的关系。
内部和外部质量的质量模型将软件质量属性分类为6个特性,即功能性、可靠性、易用性、效率、易维护性和易移植性,并进一步细分为27个子特性,从而构成一个有层次的树状结构,结构的最高层由质量特性组成,最低层则由软件质量属性组成。
使用质量的质量模型将软件质量属性分类为4个特性,即有效性、生产率、安全性和满意度。
获得软件的使用质量依赖于所取得的外部质量,而取得的外部质量依赖于获得必要的内部质量,所取得的内部质量又依赖于生存周期中所规定的过程的质量。
同样,为了获得所需的使用质量,就有助于确定外部质量需求,从而有助于确定内部质量需求,进而有助于确定过程的质量。
软件质量特性
功能性:
在指定条件下使用时,软件产品提供满足明确和隐含需求功能的能力;
可靠性:
在指定条件下使用时,软件产品维持规定的性能级别的能力;
易用性:
在指定条件下使用时,软件产品被理解、学习、使用及其吸引用户的能力;
6
效率:
在规定条件下,相对于所用资源的数量,软件产品可提供适当性能的能力;
易维护性:
软件产品可被修改的能力,修改可能包括修正、改进或者适应环境、需求和功能规约的变化;
易移植性:
软件产品从一种环境迁移到另一种环境的能力;
有效性:
软件产品在指定使用环境下,使用户准确、完整地获得规定目标的能力;
生产率:
软件产品在指定使用环境下,使用户花费合适的与有效性相关的资源数量的能力;
安全性:
软件产品在指定使用环境下,获得可接受的损害人类、商务、软件、财产或环境风险级别的能力;
满意度:
软件产品在指定使用环境下,使用户满意的能力。
软件质量度量能被用来确定软件系统或软件产品某属性值的一种测量方法或测量尺度。
测量尺度可以根据满足不同程度的需求细分为多个级别,如划分为两级,不能令人满意的和令人满意的;
如划分为4级,包括超出需求、达到目标、可接受的最低级别和不可接受的。
软件质量度量有内部度量、外部度量和使用质量的度量3种。
内部度量可应用于在设计和编码期间的非执行软件产品(如设计规约或源代码,能提供给用户、评价者、测试员和开发者评价软件质量,并尽早地发布质量问题。
外部度量是通过测试、操作和观察可执行软件,能提供给用户、评价者、测试员和开发者评价软件质量。
使用质量的度量是在指定使用环境下,测量有效性、生产率、安全性和满意度达到所规定的目标的程度。
最初由Rubey和Hartwick于1968年提出了一些属性的测量方法,但未建立质量度量体系。
Boehm等人于1976年提出了定量地评价软件质量的概念,并提出了60个质量度量公式,并首次提出了软件质量度量的层次模型。
1978年Walters和McCall提出了从软件质量要素、准则到度量的3层次软件质量模型,将质量要素降到11个。
上海计算机软件中心于1988年提出了软件质量评价体系,由6个质量特性和22个评价准则,以及众多的度量和度量元构成了一个4层次树状模型,并提出了评价准则与质量特性的关系和应用策略。
国际标准化组织于1991年制定了ISO/IEC9126-1991标准,给出了6个特性和21个子特性,又于1994年开始对ISO/IEC9126修订,直到2001年才完成修订工作,现已被两个系列标准“ISO/IEC14598软件工程产品评价”和“ISO/IEC9126软件工程产品质量”所取代。
软件质量评价过程由于评价的出发点不同,可分为3种评价过程:
其一,开发者用的过程,计划开发新产品或增强现有产品时为了预测最终产品质量指标;
其二,需求方用的过程,计划获取或复用某个已有产品时,为了决定接受产品或者从众多可选产品选择某个产品;
其三,评价者用的过程,应开发者、需方或其他机构的请求,对产品进行独立评估,它们通常是第三方机构。
不论哪一种评价过程,都是首先要确立评价需求,然后是规
第1章软件测试引论7
定评价、设计评价和执行评价等活动。
确立评价需求应确立评价目的,确定产品类型(中间制品、最终产品,规定质量模型;
规定评价包括选择度量、建立度量评定等级、确立评估准则;
设计评价包括制定评价计划;
执行评价包括进行度量、与评估准则相比较,评价结果。
早在20世纪60年代末,已经有人讨论大型软件开发项目的组织管理问题。
随着软件工程在实践过程中发生的问题,人们认识到软件产品和软件项目的开发,不完全取决于软件开发方法。
与程序的复杂性和系统的复杂性相比,前者已得到较大的缓解,更重要的是后者。
如进度推迟、经费超支、质量差、软件人员不称职,均与管理有关。
自20世纪80年代初,软件界就关注“软件过程”。
1984年10月在美国召开的第一届国际软件过程讨论会,正式提出了“软件过程”的概念。
1991年9月美国电气和电子工程师学会(IEEE的标准化委员会制定了“软件生存周期过程开展”标准。
1994年国际标准化组织和国际电工委员会(ISO/IEC制定了“软件生存周期过程”标准草案,1995年正式公布了“ISO/IEC12207-1995信息技术软件生存周期过程”国际标准。
同时,在国际标准化组织中质量管理和质量保证技术委员会(ISO/TC176制定了ISO9000簇标准,共有27个标准。
其中有一个“ISO9000-3质量管理和质量保证——第3部分”,主要针对软件开发、供应、安装和维护中的使用指南,其1997版替代了1993版,内容已大多数和ISO/IEC12207-1995相吻合,读者可以参考清华大学出版社于1999年出版的《软件企业ISO9000质量体系的建立和认证》一书。
20世纪80年代中期,IBM在WattsS.Humphrey的指导下,RonRadice等人将成熟度框架首次应用于软件过程,并由Humphrey于1986年将此成熟度框架带到卡内基·
梅隆大学的软件工程研究所(CMU/SEI。
应美国联邦政府要求,为其提供一个评价软件开发商能力的方法,1986年11月,CMU/SEI在MITRE公司的帮助下开始设计过程成熟度框架,以此帮助软件机构改进他们的软件过程。
1987年9月,CMU/SEI发表了一个简短的软件过程成熟度框架。
其后在Humphrey的《管理软件过程》一书中进行扩充。
书中提出了软件过程评估和软件能力评估,和成熟度问卷,用于评估软件过程成熟度。
基于这些设想,由JimWithey,MarkPaulk和CynthiaWise在1990年推出了最早的草案。
1991年8月MaryBethChrissis和BillCurtis帮助MarkPaulk校订,推出了CMM(成熟度模型1.1版。
CMU/SEI原先计划在1997年下半年推出2.0版,1998年推出2.1版。
但由于种种原因,未能按计划推出2.0版。
由于美国联邦政府的大力推行,CMM模型得到了广泛应用,CMU/SEI于2001年公布了通过CMM评估的软件机构共有964家,并对其作了统计分析。
目前CMM本身还在向纵深发展,CMM家族有:
8
软件能力成熟度模型(SW-CMM
软件获取能力成熟度模型(SA-CMM
人员能力成熟度模型(People-CMM
系统工程能力成熟度模型(SE-CMM
集成产品开发能力成熟度模型(IPD-CMM
个体软件过程(PSP
群组软件过程(TSP
另外,国际标准化组织为组织软件过程评价标准的制订,成立了“软件过程改进和能力确定(SoftwareProcessImprovementandCapabilityDetermine,SPICD”项目,ISO/IECJTCI的SC7分技术委员会于1996年9月正式公布了工作草案,代号为15504,即ISO/IECTR15504InformationTechnology—SoftwareProcessAssessment。
CMM的广泛采纳和成功推广,推动了软件及其他学科的类似模型的开发,从而模型繁衍,导致了过程改善目标和技术的冲突。
要求的培训工作有了相当大的增长,部分实践人员在应用各种不同的模型来实现特定的需要时产生了混淆。
针对这种情况,美国联邦政府、产业界和CMU/SEI于1998年启动了“能力成熟度模型集成(CapabilityMaturityModelIntegration,CMMI”项目,于2000年第四季度发布了第一个正式的CMMI,最近的修改是2002年6月10日。
CMMI包括了大量的工程改善和过程改善的信息,提供了单一的集成化框架来改善跨越几个学科的机构的工程过程,从而提高机构过程改善的质量和有效性。
相信CMMI将会逐步替代CMM。
另外我国也非常重视CMM的研究和应用,目前已经参照CMM1.1版制定国家军标“军用软件成熟度模型”,以及参照CMMI制定行业标准“ST/T11234软件过程能力评估模型”和“ST/T11235软件能力成熟度模型”。
1.4软件测试
1.4.1软件测试的重要性
计算机和程序是一对孪生兄弟,自从计算机诞生之日就必须要有程序在其上运行。
为了使所编制的程序能在计算机上运行,从而得到问题的正确解,必须对程序的功能性进行测试。
所以,软件测试工作是在软件工程诞生之前就客观存在了,一直延用至今,且其测试的内容和技术也有了较大的发展。
第1章软件测试引论9
无论是ISO9000的质量体系认证,还是CMU/SEI的CMM认证,其中均涉及到测试,如ISO9000中共有19个要素,其中一个要素就是“检验和试验”,对于软件来说就是测试;
再如CMU/SEI的CMM中共有18个过程关键域,其中有一个质量保证过程关键域,就是对过程的监视和测量。
因此,无论从何种角度讲,软件测试是一个必不可少的活动,是对软件需求分析、设计规约和编码的最终复审;
是软件质量保证的关键步骤。
软件测试是根据软件开发各阶段的规约和软件的内部结构,精心设计一批测试用例(包括输入数据及其预期的输出结果,并利用这些测试用例去运行程序,以发现软件中不符合质量特性要求(即缺陷或错误的过程。
目前,许多软件开发机构将研制力量的40%以上投入到软件测试之中,体现了充分重视软件质量要求。
众所周知,软件中存在的缺陷甚至是错误,如果遗留到软件交付投入运行之时,终将会暴露出来。
但到那时,不仅改正这些缺陷所花的代价更高,而且往往造成恶劣的后果。
由此可知软件测试的重要性。
软件测试不等同于程序测试。
软件测试应当贯穿软件生存周期全过程。
因此,需求描述、需求规约、设计规约、模块设计书以及程序等都应成为软件测试的对象。
换句话说,软件测试包括程序测试和各类文档的评审,这就是对软件测试的广义理解。
相对的狭义理解就是程序测试,但也不等于程序编好了才进行测试。
在进行软件产品或软件系统开发时,主要有3类人员必须参与,他们是项目经理、开发人员和测试人员。
一般来说,大家都会十分重视开发工作,因此在一个项目组中,会有很多的开发人员,而测试人员都比较少。
经过多次实践后,才会增加测试人员,如微软公司就是这种情况。
目前软件测试人员就比较多了,如Exchange2000,项目经理23人,开发人员140人,测试人员350人;
再如Windows2000,项目经理250人,开发人员1700人,测试人员3200人,可以看出测试人员和开发人员之比,竟达5∶3。
对于我国当前的软件企业来说,软件测试的力度远远不够,随着市场的成熟和企业的发展,必将会
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 引论 概要