1、软件测评技术 第一部分,测试成果及管理,测试成果及管理提要,认识软件测试 失效及其管理 缺陷及其管理,认识测试的定义,由人工或自动方法来执行或评价系统或系统部件的过程，以验证它是否满足规定的需求； 或 识别出期望的结果和实际结果之间有无差别。,认识测试的对象,软件被广泛应用，承担许多关键与核心任务 软件是被开发或设计的，包括维护阶段 软件是逻辑产品，可视性低 软件是复杂的，输入空间无限大，可执行路径特别多 大多数软件是定制的，可选标准构件少 既可能运行在芯片上，也可能运行于大型系统中,认识测试的发展历程,认识测试的目的,发现软件中隐藏的缺陷或其征兆； 验证软件是否满足其规格说明的规定和要求；
2、为软件产品质量的评价提供依据，为软件开发过程的改进提供支持。,认识测试的焦点,开发过程中的工作产品 软件需求规格说明 软件设计文档 软件源代码 软件产品 软件目标代码 用户文档,认识测试的独立性,开发人员的测试 专职测试人员的测试 专职测试团队的测试 独立机构的测试 用户的测试,认识测试与调试,测试不是调试，调试也不是测试，实际工作中人们却常将测试与调试混为一谈 主要区别： 测试是一种检验，调试是推理过程 测试从已知条件开始，使用预先定义的规程并且有可预知的结果；调试的开始条件可能不可知，结果不可预见 测试经常由非程序设计人员完成，调试必须由程序设计者完成,认识验证与确认,验证(Verific
3、ation)与确认(Validation)是广泛认可的质量保证方法和手段 验证是指对开发过程中某项规定活动进行检查的过程，以确保该活动实现了规定能力 确认是指审查已建立的软件产品是否符合客户需要的过程,V&V Verification: Are we building the product right? Validation: Are we building the right product?,认识验证与确认,认识测试的公理,公理1 不可能对程序进行完全的测试 局限 无法确信规格说明100%正确 无法确信可以达到100%的软件测试 无法保证测试环境100%满足测试要求 期望 证实给定的软件
4、满足其规格说明,认识测试的公理,公理2 测试无法说明软件没有缺陷 局限 软件质量体现在多个方面，但首先要面对并必须解决的是软件缺陷，在资源制约和技术限制的条件下，无法保证找到软件中所有的缺陷 期望 在给定的时限内尽可能多的发现缺陷和隐患,认识测试的公理,公理3 发现问题越多地方, 潜在的问题也更多 局限 不可能通过测试获得100%的质量信心 无法确信测试系统(或环境)的正确性 无法确信测试人员完全理解了软件 没有足够的资源彻底完成软件测试 期望 为软件产品质量的评价提供依据,认识测试的地位,软件测试是软件验证与确认的重要组成部分 有效的测试对于开发可靠、安全和成功的软件是必须的 测试不是“银弹
5、(silver bullet)”，它具有有效范围，它不能替代其它软件工程方法的作用,认识与其他活动的关系,认识测试的主要成果,软件缺陷 软件缺陷的征兆 故障 失效 异常注：相关定义来自IEEE Std 1633-2008 IEEE Recommended Practice on Software Reliability,认识缺陷,缺陷(Defect) 存在于软件中的、不期望的或不可接受的偏差。在特定的状态下，导致软件不能完成所需的任务 典型的软件缺陷 数组越界使用 计算表达式错误 算法实现错误,认识故障,故障(Fault) 软件中缺陷的体现。如：软件的计算或判断与规定的不符合等 一个故障如果发
6、生，可能引起失效 典型的软件故障 资源泄露 执行了多余的循环 无限递归调用,认识失效,失效(Failure) 系统或系统部件不能在规定的限制内完成所需功能 功能单元完成所需功能的能力被终止 程序的运行偏离了其需求,认识异常,观察到异常 (征兆),软件失效,测试失效,软件缺陷 (原因),测试缺陷 (原因),开发人员错误,测试人员错误,可能造成,可能表现为,可能是,认识征兆与原因,征兆和原因有可能在“地理上”是分离的 征兆有可能会因为其他问题的解决而消失 征兆有可能是间歇性的 原因有可能会归结于非错误之间的组合 原因有可能会归结于系统或编译器错误 原因有可能会归结于每个人都相信的假设,认识失效与缺
7、陷的关系,认识错误,错误(Error) 在软件开发过程中出现的不符合期望或不可接受的人为差错 典型的错误 误解或遗漏了用户需求 设计没有完整的实现软件需求 程序设计错误,认识软件测试发展动态,国外的情况 测试是开发过程的常规活动 测试技术的利用趋于科学 国内的情况 专业机构的情况 开发机构的情况 评价技术的使用还较局限,认识软件测试标准进展,ISO/IEC25051:2006 Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Requirements for qualit
8、y of Commercial Off-The-Shelf (COTS) software product and instructions for testing,认识软件测试标准进展,GB/T 25000.51-2010 软件工程 软件产品质量要求和评价(SQuaRE)商业现货(COTS)软件产品的质量要求和测试细则,认识软件测试标准进展,ISO/IEC/IEEE 29119:2013 Software and systems engineering - Software testing,认识软件测试标准进展,ISO/IEC 25010:2011 Systems and software
9、engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models,认识软件测试标准进展,质量,特性1,特性2,特性3,特性n,子特性1,子特性2,子特性n,属性1,属性2,属性n,属性1,属性2,属性3,属性n,认识软件测试标准进展,ISO/IEC 25010: 2011 Software product quality model Functional stability Reliability Performance eff
10、iciency Usability Security Compatibility Maintainability Portability,认识软件测试标准进展,ISO/IEC 25010:2011 Functional stability Functional completeness Functional correctness Functional appropriateness,认识软件测试标准进展,ISO/IEC 25010:2011 Reliability Maturity Availability Fault tolerance Recoverability,认识软件测试标准进展,
11、ISO/IEC 25010:2011 Performance efficiency Time behavior Resource utilization Capacity,认识软件测试标准进展,ISO/IEC 25010:2011 Usability Appropriateness recognizability Learnability Operability User error protection User interface aesthetics Accessibility,认识软件测试标准进展,ISO/IEC 25010:2011 Security Confidentiality
12、Integrity Non-repudiation Accountability Authenticity,认识软件测试标准进展,ISO/IEC 25010:2011 Compatibility Co-existence Interoperability,认识软件测试标准进展,ISO/IEC 25010:2011 Maintainability Modularity Reusability Analyzability Modifiability Testability,认识软件测试标准进展,ISO/IEC 25010:2011 Portability Adaptability Installa
13、bility Replaceability,认识软件测试标准进展,ISO/IEC 25040:2011 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Evaluation,失效失效状态,考虑到相关的操作及环境条件，由一个或多个失效引起或作用的对系统的直接和后继的影响 不同的失效状态对可靠性的影响具有差异,失效Therac-25,事件 Atomic energy of Canada Ltd开发的Therac-25放射治疗仪 1985.61
14、987.1, 6人治疗过量, 其中3人死亡,失效Therac-25,原因 主循环中存在竞争条件 寄存器溢出,失效Therac-25,教训 系统安全性分析、风险分析未包含软件 Therac-25重用了T-20的软件，假设和前提发生了改变，但未受到关注,失效Ariane 5,事件 1996年6月4日，Ariane5 发射40秒后爆炸,失效Ariane 5,直接原因 将一个64位浮点值转换为16位有符号整数值时，超出了16位整数的表示范围，而这个异常未得到正确处理,失效Ariane 5,经验教训 作了Ariane 5和Ariane 4具有相同环境的假设，重用软件在新的环境下完全没有进行测试 错误处理
15、模块的处理机制不正确,失效火星探测器,事件 1999年，火星气象卫星(Mars Climate Orbiter)到达火星之后不久就消失 1999年，火星极地登陆者(Mars Polar Lander)在火星上着陆时坠毁。,失效火星探测器,原因 地面系统软件和飞行器上软件分别使用公制和英制两种单位。,失效火星探测器,教训 没有进行充分的测试； 发现异常时，没有被恰当的解释。,失效其他案例,723事件 银联 出租车计价器 GE医疗软件因失效主动召回 ,失效?,列举你所见、所闻的失效,失效分级,失效状态可划分为不同的等级 软件失效的分级可以依据不同的前提 所带来的安全风险 所造成的经济损失 对系统任
16、务的影响,失效分级的作用,根据软件失效的级别，通过可靠性分析，找出关键的软件部件(子系统/配置项/部件/单元/功能)，进行重点管理，降低开发风险 对软件进行分级管理 关键/重要/一般 A/B/C/D/E 根据软件失效的级别，识别关键功能，进行标识和追踪管理,失效分级举例1,失效分级举例2,失效分级举例3,失效FRACAS,FRACAS是“Failure Report Analysis and Corrective Action System”的缩写，是“失效报告、分析及纠正措施系统” FRACAS通常也称为“失效信息闭环管理系统” 是跟踪系统可靠性的方法 是一组过程、规则和软件工具 在产品生存
17、期后端开始使用,失效FRACAS的角色,工作系统视角 组织机构(各方代表) 人员职责分工 工作的流程 资源保障,失效FRACAS的角色,信息系统视角 与可靠性信息系统的关系 信息准确与完整性 及时性、正确性 可追踪性,失效FRACAS的作用,及时有效地处理当前故障 过去发生的故障不再重现 建立企业的可靠性经验,失效FRACAS的目标,利用“信息反馈，闭环控制”的原理，通过一套规范化的程序，使发生的产品故障能得到及时的报告和纠正，从而实现产品可靠性的增长，达到对产品可靠性和维修性的预期要求，防止故障再现 通过FRACAS建立企业问题/故障信息数据库，为软件可靠性设计和分析以及关于维修策略、保障策
18、略和备件策略的制定提供数据支持,失效FRACAS流程,记录事件 分析失效模式 开展纠正活动 检验纠正活动 识别失效趋势 确定单个部件对失效产生的作用,失效FRACAS实施,故障记录,故障报告,故障分析,纠正措施,闭环管理,售后服务 数据库,FRACAS 数据库,外场故障,厂内故障,失效FRACAS进化,失效FRACAS文档,故障记录表 故障报告表 故障分析表 纠正措施表 闭环管理表,失效利用FRACAS,FRACAS 数据库,FMEA,设计准则,可靠性评估,可靠性 增长计划,故障模式手册,关键件判定 和故障历史,使用、故障、 维修信息,故障统计分析,缺陷软件的缺陷属性,无法提供无缺陷的软件，缺
19、陷已成为软件的固有属性和特征 各种研究报告表明，每写1000行代码会产生 30到85个缺陷 大多数缺陷可通过测试捕获 在大量的已完成测试的软件中，每1000行代码仍存在0.53缺陷 软件缺陷有可能会给系统质量尤其是可靠性带来重大影响,缺陷求和的例子,# include int sum(i1, i2, i3) int i1;int i2;int i3;return (i1+i2+i3); int main() printf(“Sum is %dn”, sum(1,2,3);return(0) ,缺陷排序的例子,#include int main() int a,b,c;a = 7;b = 5;c
20、 = 3;if(abc)std:cout“a,b,c are in ordern”;elsestd:cout“a,b,c are mixed upn”;return(0); ,缺陷?,列举你所见、所闻的缺陷,缺陷缺陷的影响,缺陷可能导致失效 同样的缺陷在不同的场景下导致的失效状态会有很大的差别，可能只是使用不便，也有可能带来灾难 缺陷的复杂度与失效的严重性之间的关系是未知的 最大限度的减少缺陷, 可以提高软件的可靠性,缺陷基本特性,变异的预期常常产生缺陷 在实际项目中完全消除缺陷是不可能的，基于软件开发经济学的考虑，减少缺陷是现实的 缺陷有可能非常简单，也有可能极其复杂 程序设计语言与缺陷的复
21、杂性和数量的关系是未知的 不论人的能力和背景，都可能产生缺陷,认识缺陷的解决策略,避错(Defect avoidance) 第一次就做正确 排错(defect removal) 早发现,早实施 容错(Defect tolerance) 有缺陷,也能正确的完成任务 恢复 选用最佳恢复策略,失效后继续工作,缺陷缺陷管理的目的,强制按照统一的流程处理缺陷 对缺陷实现全生命周期的闭环管理 依据缺陷的相对和绝对重要性来修复问题 有利于缺陷信息的清楚传达 透明的缺陷修复进展 获得更多有价值的信息 为技术支持和市场部门提供支持,缺陷缺陷管理的目标,确保应该修正的问题和缺陷都得到修正 其它均是次要问题,缺陷避
22、免滥用,个人业绩监控 开发与测试人员的弹药库,缺陷缺陷管理的任务,需要了解缺陷的人员一看到报告就应该明白 不会因为被相关人员遗忘而得不到修正 避免个别程序员的“即兴发挥” 增加交流,缺陷缺陷生命周期,缺陷分类法,基于来源分类 基于严重性或危害度分类 基于修复优先级分类,缺陷基于来源分类,功能 系统 过程 数据 杂类,Boris Beizer,缺陷功能类,规格 功能 测试,缺陷系统类,内部接口 硬件设备 操作系统 软件结构 资源管理,缺陷过程类,计算 初始化 控制或序列 静态逻辑 其它,缺陷数据类,类型 结构 初始化 其它,缺陷杂类,代码 文档 标准 其它 重复 NAP(不是一个问题),缺陷严重
23、性等级(1),缺陷严重性等级(2),缺陷危害度,危害度,轻微,普通,反感,严重,非常严重,灾难,传染,缺陷类型,缺陷修复优先级,立即解决 高优先级 正常排队 低优先级,缺陷分工,测试人员报告软件缺陷 分析人员分析缺陷报告 开发人员修复缺陷，并将修复集成到新的版本中 测试人员检查新的版本,缺陷测试人员的工作,负责报告缺陷 监控所报告的缺陷的解决,缺陷建立管理系统,使用商业缺陷跟踪与管理系统 自行开发专用缺陷跟踪与管理系统 创建缺陷数据库,缺陷周报,每周新发现问题总结 按功能区域和严重性分类 每周状态报告 包括对缺陷数量意外上升的解释,缺陷测试周期完成报告,当所有重要问题已经解决，结束这个测试周期
24、; 报告给出总共报告了多少缺陷，修正了多少，多少被延期。,缺陷报告的作用,报告新的缺陷 描述缺陷相关的现有信息 发现缺陷是测试的目的,缺陷报告是测试者主要的工作成果 程序员工作在时间和竞争的压力下, 缺陷报告是测试者向程序员推销应该花时间和精力去修复一个缺陷的手段,缺陷隔离,运行测试并发现了失败, 所看到的是征兆,不是潜在的缺陷 继续做工作，希望证实这个缺陷: 更严格 更一般,缺陷报告编写指南,阐述如何重现问题 分析错误使得能用最少的步数描述它 包括所有的步骤 让报告易于理解 用中立语言 保持简单: 每个报告一个缺陷 如果测试文件是重现问题的基础, 参照并附上,缺陷报告的要素,缺陷写好缺陷报告
25、,好的报告从好的测试开始 立即写报告 准确、完整而简练 发现了什么，不是做了什么,缺陷分类管理举例,正交缺陷分类(ODC，Orthogonal Defect Classification) 由IBM在1990s开发 定量管理缺陷的方法,Defect,Type,Trigger,缺陷ODC v5.11,Opener,Closer,Defect,类型 (Type),来源 (Source),影响 (Impact),触发 (Trigger),活动 (Activity),目标 (Target),界定 (Qualifier),年龄 (Age),缺陷活动(Activity),设计评审(Design Revie
26、w) 代码审查(Code Inspection) 单元测试(Unit Test) 功能测试(Function Test) 系统测试(System Test),缺陷触发(Triggers),设计评审/代码审查类触发 单元测试类触发 功能测试类触发 系统测试类触发,缺陷触发(Triggers),设计评审/代码审查类触发 设计一致性(Design Conformance) 逻辑/流程(Logic/Flow) 向后兼容(Backward Compatibility) 内在文档(Internal Document) 横向兼容(Lateral Compatibility) 并发(Concurrency)
27、语言依赖(Language Dependency) 副作用(Side Effects) 特殊情况(Rare Situation),缺陷触发(Triggers),单元测试类触发 简单路径(Simple Path) 复杂路径(Complex Path),缺陷触发(Triggers),功能测试类触发 有效区域覆盖(Coverage) 变异(Variation) 定序(Sequencing) 交互(Interaction),缺陷触发(Triggers),系统测试类触发 工作负荷/压力(Workload/Stress) 恢复/异常处理(Recovery/Exception) 启动/重启动(Startup
28、/Restart) 硬件配置(Hardware Configuration) 软件配置(Software Configuration) 闭塞测试(Blocked Test (previously Normal Mode),缺陷影响(IMPACT),Installability Integrity/Security Performance Maintenance Serviceability Migration Documentation Usability,Standards Reliability Requirements Accessibility Capability,缺陷目标(Targ
29、et),Requirements Design Code Build/Package Information Development National Language Support,缺陷类型(Type),Assignment/Initialization Checking Algorithm/Method Function/Class/Object Timing/Serialization Interface/O-O Messages Relationship,缺陷界定(QUALIFIER),遗漏(Missing) 错误(Incorrect) 多余(Extraneous),缺陷来源(SOURCE),本项目组开发(Developed In-House) 库函数重用(Reused From Library) 外部(Outsourced) 移植 (Ported),缺陷年龄(AGE),早期版本(Base) 新开发(New) 优化重写(Rewritten) 重新修复(ReFixed),问题?,
