《课件01-软件测试-成果》由会员分享，可在线阅读，更多相关《课件01-软件测试-成果（115页珍藏版）》请在金锄头文库上搜索。
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 quali
8、ty 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 ef
10、ficiency 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 Install
13、ability 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.6
14、1987.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通常也称为“失效信息闭环管理系统” 是跟踪系统可靠性的方法 是一组过程、规则和软件工具 在产品生存期后端开始使用,失效FRACAS的角色,工作系统视角 组织机构(各方代表) 人员职责分工 工作的流程 资源保障,失效FRACAS的角色,信息系统视角 与可靠性信息系统的关系 信息准确与完整性 及时性、正确性 可追踪性,失效FRACAS的作
