1第7章软件的质量与测试软件工程研究室2主要内容7.1软件的质量7.2软件的测试目的:测试是软件质量保证中至关重要的一个环节3主要内容7.1软件的质量7.1.1软件的质量观7.1.2软件质量的特征7.1.3软件质量因素7.1.4软件质量要素之间的关系7.1.5质量保证的几个问题47.1.1软件的质量观7.1软件的质量高质量客户:在可接受的资金和资源成本下解决问题用户:易学习;使用效率高;对工作有帮助开发:易设计;易维护;易重用管理人员:销售量大并使客户满意,同时开发和维护的费用少5Juran的质量观:产品在使用时,能适合用户需要的目标程度。ISO的质量观:“一个产品或服务是否能够满足其指定的或蕴含的需求有关的性质与特征总和”.7.1.1软件的质量观7.1.2软件质量的特征(1)很难制定具体的、数量化的产品质量标准没有相应的国际标准、国家标准或行业标淮(2)大部分软件很难做到“零缺陷”对软件的测试不可能穷尽所有情况,有缺陷的软件仍然可以使用软件产品的不完善可通过维护和升级解决问题(3)软件的类型不同,软件质量的衡量标准的侧重点也不同。对实时系统,可靠、效率是衡量软件质量的首要要素对一些需要用户与软件本身进行大量交互的系统,对可用性(usability)就提出了较高的要求。7.1.2软件质量的特征(6)如果软件只满足了己经定义的需求,而没有满足一些隐含的需求,软件质量也不能保证。(4)软件产品之间很难进行横向的质量对比(5)软件需求是度量软件质量的基础,满足了用户需求的软件质量,就是好的软件质量。即使软件在技术上很先进,界面很漂亮,功能也很多,但不是用户所需要的,仍不能算软件质量好。功能性(Functionality)可靠性(Reliability)可用性(Usability)效率(Efficiency)可维护性(Maintainability)可移植性(Portability)7.1.3软件质量因素1)ISO质量特性国际标准(ISO/IEC9126)1991年,ISO发布了ISO/IEC9126质量特性的国际标准,将质量特性降为6个,并定义了21个子特性:1)ISO质量特性国际标准(ISO/IEC9126)图7-1ISO软件质量模型外部和内部质量适合性准确性互操作性保密安全性功能性可靠性易用性维护性可移植性效率成熟性容错性易恢复性易理解性易学性易操作性吸引性时间特性资源利用性易分析性易改变性稳定性易测试性适应性易安装性共存性易替换性102)McCall软件质量模型(1977):产品修改产品改型图7-2McCall软件质量模型外部质量属性(externalqualityattribute)易移植性易复用性互用性易维护性灵活性易测试性产品操作易使用性正确性可靠性高效性完整性11每个要素包含系列衡量标准正确性易追溯性:从需求中找到实现能力完备性:实现了所有的功能一致性:一致的术语和技术高效性运行效率:使用最少的处理时间存储效率:使用最小的内存空间可靠性容错性:异常,仍能操作一致性准确性简洁性易使用性易操作培训易交流输入输出量和速度灵活性一致性模块性易扩展性自我描述性互用性模块性通讯共同性数据共同性13易测试性检视:测量、识别错误能力简洁性自我描述性模块性模块性易移植性软件独立性硬件独立性自我描述性14易复用性软件独立性通用性模块性硬件独立性自我描述性易维护性简明性:代码少简洁性:易理解模块性一致性自我描述性:有解释15总体效用易维护性现存效用易移植性易修改性易理解性易测试性效率人机界面可靠性易更改性可认性简明性结构性自我描述性易交流性易存取性设备效率可依靠性一致性完整性准确性自我包含性硬件独立性图7-3Boehm模型3)Boehm模型(1978)16McCall和Boehm模型从用户出发的质量观.都是层次结构的模型.根据具体情况决定质量要素的相对重要性.7.1.4软件质量要素之间的关系质量由多种因素组成,但互不独立,也不一定同等重要,可能是冲突的.在一定前提下来衡量质量,不能脱离代价来衡量产品的质量.17软件质量要素之间的关系正确性可靠性效率完整性易使用性易维护性易测试性灵活性易移植性易复用性互用性正确性可靠性效率完整性易使用性易维护性易测试性灵活性易移植性易复用性互用性直接相关反向相关图7-4Perry的质量要素之间关系18提高效率可能会使设计不宜理解,会降低系统的可维护性。实现高可靠性通常要求反复地进行错误检查并添加一些冗余计算。提高效率可能要求删除这些检查和冗余。改善可用性可能需要添加额外的代码为用户提供反馈信息,这又可能降低整体效率。良好的工程实践,项目开始就应设定质量目标,目标的实现应让所有相关人员都满意。为了在市场竞争中取得成功,在不超过预算和满足其他质量目标要求的同时,使某个质量属性达到最优化(optimize)。19内部质量属性:代码注释量,影响可维护性,间接影响可靠性;代码的复朵性,影响可维护性、可靠性。说明:注重短期需要而忽视决策的长期影响是人类的天性.这可能引发严重后果。只考虑短期效果,可能忽视系统的可维护性,忽视客户的长期需要,导致过高的后期成本。20几个思考题:下面的问题与哪些质量属性有关.一段宇宙飞船程序,使宇宙飞船进入冥王星轨道.一个在购物中心运行的系统.使用该系统,购物者可以确定哪个商店出售他们需要的商品.汽车自动变速器的控制程序.打印票据的实用软件包.计算所得税的程序,公务员可以使用该程序检查纳税人的账目.1)软件质量应贯穿软件开发的全过程软件质量管理该贯穿软件开发的全过程,而不仅仅是软件本身。7.1.5质量保证的几个问题2)对开发文档的评审需求规格说明书设计规格说明书代码文档测试报告用户手册3)运用技术手段保证质量使用多种软件工具,保证软件质量。例如:用RationalRose软件进行软件开发等。采用先进的系统分析方法和软件设计方法4)以满足客户和用户需要为目标的质量保证(3)缺陷预防,控制对缺陷的修改(1)采用快速原型法(2)充分设计之后再编码(4)充分进行软件的系统测试(5)恰当掌握软件的放行标淮237.2软件测试软件测试它既令人兴奋,也令人烦脑;既令人羡慕不己,也令人望而却步;要想在预算内按时交付高质量的软件,测试是必不可少的。7.2.1软件测试概述7.2.2程序错误分类7.2.3软件测试的V模型7.2.4软件测试的分类7.2.5软件测试的方法7.2.6软件测试的步骤7.2.7软件的调试7.2.1软件测试概述1)什么是软件测试(Test)?2)为什么要测试(Test)?3)软件测试的目的4)软件测试的准则5)软件的可测试性6)软件测试与软件开发阶段7.2.1软件测试概述1)什么是软件测试(Test)?测试是采用测试用例,检测出程序的错误、缺陷、故障、失效和事故等的一项软件活动。对程序的副本提供一组有代表性的输入数据,给定的环境下运行程序副本,并对程序的输出进行检查和分析。错误(Error)称bug不正确结果的全部。由开发人员引起的,如输入错误、需求错误、设计错误等。缺陷(Defect)错误的表现结果,会促成失败的发生。由不恰当或错误的技术、算法、遗漏了某些功能或设计内容所导致。故障(Fault)故障是指系统的规格说明与其行为之间的偏差,通常由一个或多个缺陷引起。通过对比程序的实际输出与预期输出来检测。失效(Failure)故障引起的结果。系统不可接受的行为。由于错误,导致系统的错误输出─失效。发生过失效的软件通常仍然是可用的。只有当软件频繁失效,或者公认已经“过时”了的时侯,软件才被废弃,意味着当前这一版本软件使用寿命的终结。事故(Incident)呈现给用户的严重错误的结果,造成一定的或严重的损失。“千年虫”1970年代,一位程序员在开发公司的工资管理系统时,迫于计算机存储空间的限制,将4位数日期缩减为2位数(197373),从而节省了可观的存储空间;然而,世界各地更换或升级2000年问题所花的费用超过数亿美元…2)为什么要测试(Test)?“爱国者导弹”爱国者导弹vs飞毛腿导弹有一枚爱国者导弹击毙28名美军士兵…原因:导弹的软件包含一个累加计时故障,系统时钟错误积累起来就可能拖延14个小时,造成跟踪系统失去准确度。“狮子王”1994年秋天,迪斯尼公司发行《LionKingAnimated》,虽然销售量巨大,却引来巨大的、意想不到的投诉…原因:发布之前未能对该软件在各种不同类型的PC机上进行测试,导致在某些系统上无法运行。如,对一个整数组排序,应该用整数比较函数icmp调用qsort:intarr[N];qsort(arr,N,sizeof(arr[0],icmp);无意中把字符串比较函数传进去:?intarr[N];?qsort(arr,N,sizeof(arr[0],scmp);编译无法发现这类错误,程序运行时会垮台,它访问非法的存储器地址,灾难就发生了。323)软件测试的目的软件测试是对软件质量的度量,并代表了规约、设计和编码的最终评审。为找出错误而运行程序或系统的过程。(Myers,1979)软件测试概述测试是证明错误的存在,而不是证明错误的不存在。(Dijstra)确信程序做了它应该做的事。(Hetzel,1973)确认程序正确地实现了所要求的功能。334)软件测试的准则#需求确定后,制定测试计划,所有的测试应能追溯到用户需求上。软件测试概述#尽早地和不断地进行软件测试。#测试从小规模开始,逐渐扩到大规模。#独立测试组或SoftwareTestEngineer。#测试中发现8o%错误,可能由程序的20%的组件造成的(Pareto原理)。#使用或开发测试工具。345)软件的可测试性程序被测试的难易程度软件测试概述一个特定测试集覆盖产品的充分程度软件可测试性的度量特征:a.可操作性b.可观察性c.可控制性d可分解性e.简单性f.稳定性g.可理解性356)软件测试与软件开发阶段软件测试并不等于程序测试,应贯穿于软件定义与开发的各个阶段。需求阶段•用例情景测试•原型走查•模型走查•需求评审•制定测试计划设计阶段•模型走查•原型走查•设计评审•制定测试计划•测试设计实现阶段•代码走查•接口分析•文档评估•编写测试用例•制定测试过程•单元测试实现阶段•制定测试计划•集成设计•系统测试•α测试•β测试•验收测试回归测试,质量保证验收阶段表7-1软件测试与软件开发阶段367.2.2软件错误分类Beizer给出的软件错误:抽样大小—6877000条语句(含注释)总错误数—16209个错每千条语句错误数—2.36个错需求错误,功能和性能错误程序结构错误,数据错误编码错误测试定义和执行错误软件集成错误37错误分类错误数百分比(%)需求错误13178.1需求不正确6494.0需求逻辑错1530.9需求不完备2241.4需求文档描述错130.1需求变更2781.7表7-2需求错误错误分类38错误分类错误数百分比(%)功能和性能错误262416.2功能和性能不正确4562.8性能不完整2311.4功能不完整1931.2适用范围错7784.8用户信息和诊断信息错8575.3异常处理错790.5其他功能错300.2表7-3功能和性能错误错误分类39错误分类错误数百分比(%)程序结构错误408225.2控制流和控制顺序错误、变量、分支、循环等问题207812.8处理器错200412.4表7-4程序结构错误错误分类40错误分类错误数百分比(%)数据错误363822.4数据类型定义,引用及结构错180511.1数据存取及处理错183111.3其他数据错(比较、计算、精度、零为除数)2表7-5数据错误错误分类41错误分类错误数百分比(%)编码与实现错误16019.9编码与程序输入错误3322.0违反编程标准或风格3182.0文档错9605.9其他实现错10.0表7-6编码与实现错误错误分类42错误分类错误数百分比(%)测试定义和执行错误4472.8测试设计错110.1测