软件度量总结 这次总结的结构比较简单,就是按照五个章节分别阐述了自己的理解。 一.软件度量的应用范围。 经过这一阶段的学习,我认为想要明白软件度量,首先要分清度量和测量的区别。度量具有前置性,它提供了一种定量研究软件问题的方法;测量具有实时性或后置性,主要集中在给度量提供数据或者处理数据的方法上。由于软件工程强烈的不确定性,使得软件工程的精确测量困难重重,但软件度量主要研究的是可能性的规律,通过概率和统计学的研究,寻找事物内在的规律。其并不具备 1+1=2的特征, 而是研究在多大可能性上这个结论是合理的,因为软件的主体是人,具有概率属性,设备和材料容易度量,但人很难度量。软件度量的主要作用是评估状况、跟踪进展情况、评价产品有效性和改进设计和过程的质量。定性分析可以提供迅速地判断能力,但定性分析终究需要定量分析的验证与支持,否则其结果很可能成为无目之本,出现错误。 软件度量的方法体系主要包括 5个方面:1. 项目度量,目的在于度量项目规模、成本、进度、顾客满意度等,辅助项目管理进行项目控制; 2. 规模度量,主要依靠经验和经验的模型,是决定项目成败的重要原因之一,是估算工作量、成本预算及策划项目进度的基础; 3. 成本度量, 4。产品度量,实质上是软件质量的度量,软件的质量由一系列质量要素组成,每个质量要素又由一些衡量标准组成,主要肚量方法是McCabe 复杂性度量法; 5,过程度量,对软件开发过程的个各方面进行度量,目的在于预测过程的未来属性,减少结果的偏差,主要包括成熟度度量(例如 CMMI, GJB5000A、管理度量(主要包括里程碑管理、风险度量等项目管理度量,审查度量、质量保证度量等质量管理度量,变更控制、版本管理度量等配置管理度量、生命周期度量三个大的方面。 不同层次的人员对软件度量有不同的需求。高级管理人员,如 CEO 、 COO ,关注点在上市时间、客户满意度、费用的节省等商业策略的组成部分上;中级管理层,如部门经理、总监等,则主要关注生产力、成本控制、效率等,他们更多的是着眼于
浅谈软件系统可靠性 1 概述 近年来，随着计算机在军用与民用产品上的应用日益增多，软件缺陷所引发的产品故障，甚至灾难性事故也越来越严重，软件故障已成为高新技术产品发展的瓶颈。在这种情况下，一旦计算机系统发生故障，则其效益就会大幅度地消减，甚至完全丧失，从而使社会生产和经济活动陷入不可收拾的混乱状态。因此可以说，计算机系统的高可靠性是实现信息化社会的关键。 计算机系统硬件可靠性方面已有六十余年的发展历史，冗余技术、差错控制、故障自动检测、容错技术和避错技术等可靠性设计技术已经成熟。相比之下，软件可靠性的研究只有三十几年的发展历史，加上软件生产基本上仍处于作坊式的手工制作，其提高软件可靠性的技术与管理措施还处于十分不完善的状况。20 世纪70 年代末至80 年代初，软件可靠性的研究集中于对软件可靠性模型进行比较和选择。90 年代以来，软件可靠性研究工作进展较快，主要集中在软件可靠性设计、软件可靠性测试与管理以及软件可靠性数据的收集这三个方面。 2 软件可靠性的基本概念 2.1 软件可靠性的定义 1983年，美国IEEE计算机学会软件工程技术委员会对软件可靠性的定义如下： a）在规定的条件下，在规定的时间内，软件不引起系统失效的概率，该概率是系统输入和系统使用的函数，也是软件中存在的错误的函数；系统输入将确定是否会遇到已存在的错误。 b）在规定的时间周期内，在所述条件下程序执行所要求的功能的能力。 软件可靠性定义中提到的“规定的条件”和“规定的时间”，在工程中有重要的意义。 定义中的“时间”有3种度量。第一种是日历时间，指日常生活中使用的日、周、月和年等计时单元；第二种是时钟时间，指从程序运行开始到运行结束所用的时、分、秒；第三种是执行时间，指计算机在执行程序时实际占用的CPU 时间。 定义中所指的“条件”，是指环境条件，包括了与程序存储、运行有关的计算机及其操作系统。 2.2 影响软件可靠性的主要因素 软件可靠性表明了一个程序按照用户的需求和设计的目标，执行其功能的正确程度。这要求一个可靠的程序应是正确的、完整的、一致的和健壮的。软件可靠性的决定因素是与输入数据有关的软件差错，正是因为软件中的差错引起了软件故障，使软件不能满足需求。影响软件可靠性的因素主要包括： 1、软件开发的支持环境； 2、软件的开发方法；
11.1 概述 11.1.1 软件质量的定义 软件质量定义为： (1) 与所确定的功能和性能需求的一致性。 (2) 与所成文的开发标准的一致性。 (3) 与所有专业开发的软件所期望的隐含特性的一致性。 11.1.2 软件质量的度量和评价 影响软件质量的因素可以分为两大类： (1) 可以直接度量的因素，如单位时间内千行代码（KLOC）中产生的错误数。 (2) 只能间接度量的因素，如可用性或可维护性。 在软件开发和维护的过程中，为了定量地评价软件质量，必须对软件质量特性进行度量，以测定软件具有要求质量特性的程度。
11.1.3 软件质量保证 1. 什么是软件质量保证 软件的质量保证就是向用户及社会提供满意的高质量的产品，确保软件产品从诞生到消亡为止的所有阶段的质量的活动，即确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。 2. 质量保证的策略 质量保证策略的发展大致可以分为以下三个阶段： (1) 以检测为重。产品制成后才进行检测，这种检测只能判断产品的质量，不能提高产品质量。 (2) 以过程管理为重。把质量保证工作重点放在过程管理上，对制造过程的每一道工序都进行质量控制。 (3) 以新产品开发为重。 3. 质量保证的主要任务 (1) 正确定义用户要求。 (2) 技术方法的应用。 (3) 提高软件开发的工程能力。 (4) 软件的复用。 (5) 发挥每个开发者的能力。 (6) 组织外部力量协作。
(7) 排除无效劳动。最大的无效劳动是因需求规格说明有误、设计有误而造成的返工。 (8) 提高计划和管理质量。 4. 质量保证与检验 软件质量必须在设计和实现过程中加以保证。 11.2 质量度量模型 11.2.1 McCall质量度量模型 这是McCall等人于1979年提出的软件质量模型。针对面向软件产品的运行、修正、转移，软件质量概念包括11个特性，其定义如下： (1) 面向软件产品操作。 (2) 面向软件产品修改。 (3) 面向软件产品适应。 11.2.2 ISO的软件质量评价模型 软件质量度量模型由三层组成。 11.3 软件复杂性 11.3.1 软件复杂性的基本概念 软件复杂性度量的参数很多，主要有： (1) 规模，即总共的指令数，或源程序行数。 (2) 难度，通常由程序中出现的操作数的数目所决定的量来表示。 (3) 结构，通常用于程序结构有关的度量来表示。 (4) 智能度，即算法的难易程度。 软件复杂性主要表现在程序的复杂性。程序的复杂性主要指模块内程序的复杂性。它直接关联到软件开发费用的多少、开发周期长短和软件内部潜伏错误的多少。同时它也是软件可理解性的另一种度量。
软件质量指标度量 V 1.0 2012.3
目录 1综述 (3) 1.1编写目的 (3) 1.2阅读指南 (3) 2软件质量指标 (4) 2.1需求功能点覆盖率 (4) 2.2用例执行覆盖率 (4) 2.3缺陷修复率（截至于**年*月*日） (5) 2.4缺陷遗留个数（截至于**年*月*日） (5) 2.5缺陷分布统计（模块缺陷率） (5) 2.6缺陷分布统计（严重缺陷率） (6) 2.7缺陷密度及收敛 (7) 3测试过程质量指标 (9) 3.1缺陷探测率 (9) 3.2有效缺陷率 (9) 3.1用例执行效率 (10) 3.2缺陷发现率 (10) 4交付质量指标 (12) 4.1加载回退率 (12) 4.2故障回退率 (12) 5版本说明 (13)
1综述 1.1 编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的依据。 1.2 阅读指南 ●软件测试质量指标主要针对研发项目、商务项目被测产品出具数据 度量。 ●测试过程质量指标主要为测试经理、测试组长对测试人员的测试执 行质量出具数据度量。 ●交付质量主要为新需求的交付质量出具数据度量。 三者可单独使用，也可结合使用。
2软件质量指标 2.1 需求功能点覆盖率 【需求覆盖率】：计算测试用例总数之和除以与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。 【公式】：∑测试用例数（个）/ ∑功能点（个） 说明：用例覆盖需求矩阵，一个需求对应多个功能点。 【数据来源】：《联通集中集团客户业务支撑系统销售管理用户需求说明书》《联通集中集团客户业务支撑系统销售管理需求跟踪矩阵》 【计算结果】需求覆盖率=113/8=14.13 2.2 用例执行覆盖率 【用例执行覆盖率】：计算测试用例执行总数除以与之一一对应的测试数之和，主要查看是否有测试用例执行遗漏或有效的情况。 【公式】：∑执行的测试用例个数（个）/ ∑测试用例个数（个）*100% 【数据来源】：《iSMS测试进度跟踪表》 【计算结果】：用例执行覆盖率=100%
几种常见软件可靠性测试方法综述及应用对比 上海交通大学陈晓芳 [摘要]软件可靠性测试是软件可靠性工程的一项重要工作内容,是满足软件可靠性要求、评价软件可靠性水平及验证软件产品是否达到可靠性要求的重要途径。本文探讨、研究了软件可靠性测试的基本概念,分析、对比了几种软件可靠性测试主要方法的优缺点。 [关键词]软件可靠性软件可靠性测试软件测试方法 引言 软件可靠性工程是指为了满足软件的可靠性要求而进行的一系列设计、分析、测试等工作。其中确定软件可靠性要求是软件可靠性工程中要解决的首要问题,软件可靠性测试是在软件生存周期的系统测试阶段提高软件可靠性水平的有效途径。各种测试方法、测试技术都能发现导致软件失效的软件中残存的缺陷,排除这些缺陷后,一般来讲一定会实现软件可靠性的增长,但是排除这些缺陷对可靠性的提高的作用却是不一样的。其中,软件可靠性测试能最有效地发现对可靠性影响大的缺陷,因此可以有效地提高软件的可靠性水平。 软件可靠性测试也是评估软件可靠性水平,验证软件产品是否达到软件可靠性要求的重要且有效的途径。 一、软件可靠性测试概念 “测试”一般是指“为了发现程序中的错误而执行程序的过程”。但是在不同的开发阶段、对于不同的人员,测试的意义、目的及其采用的方法是有差别的。在软件开发的测试阶段,测试的主要目的是开发人员通过运行程序来发现程序中存在的缺陷、错误。而在产品交付、验收阶段,测试主要用来验证软件产品是否达到用户的要求。或者说,对于开发人员,测试是发现缺陷的一种途径、手段,而对于用户,测试则是验收产品的一种手段。
二、软件测试方法 软件测试方法有以下几个主要概念:白盒测试、黑盒测试、灰盒测试。 白盒测试(W h ite-box testing或glass-box testing是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法,溢出,路径,条件等等中的缺点或者错误,进而加以修正。 黑盒测试(B lack-box testing是通过使用整个软件或某种软件功能来严格地测试,而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。通常测试人员在进行测试时不仅使用肯定出正确结果的输入数据,而且还会使用有挑战性的输入数据以及可能结果会出错的输入数据以便了解软件怎样处理各种类型的数据。 灰盒测试(Gray-box testing就像黑盒测试一样是通过用户界面测试,但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的,甚至于还读过部分源代码,因此测试人员可以有的放矢地进行某种确定的条件或功能的测试。这样做的意义在于:如果你知道产品内部的设计和透过用户界面对产品有深入了解,你就能够更有效和深入地从用户界面来测试它的各项性能。 1、白盒测试 白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。 白盒的测试用例需要做到: (1保证一个模块中的所有独立路径至少被使用一次; (2对所有逻辑值均需测试true和false;
关于软件可靠性 什么的软件可靠性？ 软件可靠性是指在给定时间内，特定环境下软件无错运行的概率。 软件可靠性的内容 软件可靠性包含了以下三个要素： 1.规定的时间 软件可靠性只是体现在其运行阶段，所以将“运行时间”作为“规定的时间”的度量。“运行时间”包括软件系统运行后工作与挂起(开启但空闲)的累计时间。由于软件运行的环境与程序路径选取的随机性，软件的失效为随机事件，所以运行时间属于随机变量。 2.规定的环境条件 环境条件指软件的运行环境。它涉及软件系统运行时所需的各种支持要素，如支持硬件、操作系统、其它支持软件、输入数据格式和范围以及操作规程等。不同的环境条件下软件的可靠性是不同的。具体地说，规定的环境条件主要是描述软件系统运行时计算机的配置情况以及对输入数据的要求，并假定其它一切因素都是理想的。有了明确规定的环境条件，还可以有效判断软件失效的责任在用户方还是研制方。 3.规定的功能 软件可靠性还与规定的任务和功能有关。由于要完成的任务不同，软件的运行剖面会有所区别，则调用的子模块就不同(即程序路径选择不同)，其可靠性也就可能不同。所以要准确度量软件系统的可靠性必须首先明确它的任务和功能。 软件可靠性的测试 软件可靠性测试的目的 软件可靠性测试的主要目的有:
(1)通过在有使用代表性的环境中执行软件,以证实软件需求是否正确实现。 (2) 为进行软件可靠性估计采集准确的数据。估计软件可靠性一般可分为四个步骤,即数据采集、模型选择、模型拟合以及软件可靠性评估。可以认为,数据采集是整个软件可靠性估计工作的基础,数据的准确与否关系到软件可靠性评估的准确度。 (3)通过软件可靠性测试找出所有对软件可靠性影响较大的错误。 软件可靠性测试的特点 软件可靠性测试不同于硬件可靠性测试,这主要是因为二者失效的原因不同。硬件失效一般是由于元器件的老化引起的,因此硬件可靠性测试强调随机选取多个相同的产品,统计它们的正常运行时间。正常运行的平均时间越长, 则硬件就越可靠。软件失效是由设计缺陷造成的,软件的输入决定是否会遇到软件内部存在的故障。因此,使用同样一组输入反复测试软件并记录其失效数据是没有意义的。在软件没有改动的情况下,这种数据只是首次记录的不断重复,不能用来估计软件可靠性。软件可靠性测试强调按实际使用的概率分布随机选择输入,并强调测试需求的覆盖面。软件可靠性测试也不同于一般的软件功能测试。相比之下,软件可靠性测试更强调测试输入与典型使用环境输入统计特性的一致,强调对功能、输入、数据域及其相关概率的先期识别。测试实例的采样策略也不同,软件可靠性测试必须按照使用的概率分布随机地选择测试实例,这样才能得到比较准确的可靠性估计,也有利于找出对软件可靠性影响较大的故障。 此外,软件可靠性测试过程中还要求比较准确地记录软件的运行时间,它的输入覆盖一般也要大于普通软件功能测试的要求。 对一些特殊的软件,如容错软件、实时嵌入式软件等,进行软件可靠性测试时需要有多种测试环境。这是因为在使用环境下常常很难在软件中植入错误,以进行针对性的测试。 软件可靠性测试的效果 软件可靠性测试是软件可靠性保证过程中非常关键的一步。经过软件可靠性测试的软件并不能保证该软件中残存的错误数最小,但可以保证该软件的可靠性达到较高的要求。从工程的角度来看,一个软件的可靠性高不仅意味着该软件的失效率低,而且意味着一旦该软件失效,由此所造成的危害也小。一个大型的工程软件没有错误是不可能的,至少理论上还不能证 明一个大型的工程软件能没有错误。因此,保证软件可靠性的关键不是确保软件没有错误,而是要确保软件的关键部分没有错误。更确切地说,是要确保软件中没有对可靠性影响较大的错误。这正是软件可靠性测试的目的之一。软件可靠性测试的侧重点不同于一般的软件功能测试,其测试实例设计的出发点是寻找对可靠性影响较大的故障。因此,要达到同样的可靠性要求,可靠性测试比一般的功能测试更
IEEE软件可靠性系列标准分析 摘要：对IEEE软件可靠性系列标准进行分析，总结了IEEE制定软件可靠性标准的经验，以及软件可靠性发展趋势。同时，结合我国软件可靠性标准化工作现状，提出软件可靠性标准的制定及相关标准修订的可借鉴之处。关键词：软件可靠性标准；软件可靠性度量；软件可靠性评估过程；软件可靠性模型 随着计算机技术的快速发展，现代航电系统大量使用软件系统，其中某些软件系统在保证航空系统安全、可靠完成任务时起到了至关重要的作用，但这些软件的失效可能导致灾难性后果。为了提高软件可靠性，相关领域的学者展开了广泛的软件可靠性研究，特别是全球最大的专业学术组织IEEE，更是在这方面作出了卓越的成绩。IEEE在开展软件可靠性研究的同时，也非常重视相关标准的制定工作。1988年，IEEE制定了第一份关于软件可靠性度量体系方面的标准[1]以及该标准的实施指南[2]。2005年，IEEE对软件可靠性度量体系标准进行了修订[3]。2008年，IEEE对R-013-1992标准进行修订 [4]，R-013-1992标准是AIAA(美国航空与航天学会)在1992年制定的关于软件可靠性评估的标准[5]，这也说明IEEE在软件可靠性方面的成绩是国际公认的。IEEE主要制定了软件可靠性度量体系和评估两方面的标准。本文将对IEEE制定的软件可靠性标准进行介绍和分析，总结IEEE制定软件可靠性标准的经验，以及软件可靠性发展趋势，结合我国软件可靠性标准现状，提出可靠性标准的制定及相关标准修订的可以借鉴之处。1 IEEE软件可靠性标准分析1.1 标准简介IEEE软件可靠性标准主要包括软件可靠性度量体系和软件可靠性评估两方面。其中，软件可靠性度量体系由IEEE Std 982.1-2005(软件可信性度量词典)和IEEE Std 982.2-1988(软件可靠性度量实施指南)组成，IEEE Std 982.1-2005是IEEE Std 982.1-1988的修订版；软件可靠性评估主要包括IEEE Std 1633-2008(软件可靠性操作规程)，它发布于2008年，替代了AIAA/ANSI R-013-1992(软件可靠性操作规程)。在IEEE软件可靠性标准体系中，IEEE Std 982.1-2005主要回答了使用哪些参数对软件可靠性进行度量的问题，即用户可以通过哪些方面对软件质量、特别是软件的可靠性进行了解和评价。与IEEE Std 982.1-1988相比，IEEE Std 982.1-2005作出了较大程度的修改。1988版关于软件可靠性属性有39个不同的度量参数，而2005版中只有12个，并且其中75%的度量参数是新增或修改的。IEEE Std 982.2-1988主要回答了如何使用这些度量参数对软件可靠性进行度量的问题，但是该标准主要是针对IEEE Std 982.1-1988度量参数体系的，而IEEE Std 982.1-2005中有75%的度量参数和IEEE Std 982.1-1988不一样。因此，对于当前的软件可靠性度量参数体系，该标准实际上已经失去了指导意义。IEEE Std 1633-2008主要解决了如何进行软件可靠性评估的问题，包括软件可靠性评估过程和软件可靠性评估模型两方面。其中，软件可靠性评估过程包含13个步骤，这些步骤不是全部必需的，可根据软件特点和当前所处的软件生命周期阶段进行删减；软件可靠性评估模型方面推荐了三个模型，这三个模型都是在实际工程中表现优异的评估模型。1.2 软件可靠性度量参数体系IEEE Std 982.1-2005是IEEE Std 982.1-1988的修订版，它体现了软件可靠性作为软件质量重要属性在软件质量控制方面的新方法和新趋势。与1988版相比，2005版作出了较大程度的修改。1988版关于软件的可靠性属性有39个不同的度量参数，而2005版删除了其中的32个度量参数，并对剩余度量参数中4个进行了修改，只有3个得到完全保留，同时新增了5个度量参数。即可靠性度量参数由原来的39个变更为12个，其中有75%的度量参数是新增或修改的。可以说2005版基本上重新定义了软件可靠性的度量体系，新度量参数体系如表1所示。IEEE在选取度量参数建立软件可靠性度量参数体系时，有如下准则：(1)该参数是否得到了学术界和工业界的公认；(2)该参数是否能有效地反映出软件可靠性的真实情况；(3)该参数是否过于复杂，以至难于使用和理解；(4)该参数适用情况是否过于狭小。从IEEE选取度量参数的准则可以看出，软件可靠性度量的发展
软件可靠性的评价准则 迄今为止,尚无一个软件可靠性模型对软件的不同特性和不同使用环境都有效。已公开发表的100余种软件可靠性模型,表达形式不同,适应性各异,与实际的软件开发过程有较大差异。而且,新模型还在不断发表。因此,在进行软件可靠性预计、分析、分配、评价和设计之前,对软件可靠性模型进行评价及选择与软件项目相符或相近的模型非常重要。通过建立有效的评价准则,在考虑它们与各种软件的关系的基础上,对拟评价的可靠性模型就有效性、适应性和模型能力等进行评价,判定它们的价值,比较它们的优劣,然后选择有效的软件可靠性模型。另一方面,在可接受的模型之间无法做出明确的选择时,可根据模型的使用环境等,在模型评价准则的基础上,进行模型择优。当然,软件可靠性模型的评价不仅依赖于模型的应用,还依赖于理论的支持和丰富的、高质量可靠性数据的支持。软件可靠性模型的评价最早始于1984年Iannino、Musa、Okumoto和Littlewood所提出的原则。根据这一原则,结合后人的工作,形成了基本的软件可靠性评价准则集。它们是软件可靠性模型比较、选择和应用的基础。 准则一:模型预测有效 软件可靠性模型最重要的评价指标是模型预测的有效性。它根据软件现在和过去的故障 行为,用模型预测软件将来的故障行为和可靠性水平。它主要通过能有效描述软件故障随机过程特性的故障数方式对模型进行描述与评价。基于软件故障时间特性的随机过程也是一种常用的方法,而且这两种方法相互重叠。 要确定软件可靠性模型预测的有效性,首先要比较模型预测质量。这种比较通常通过相 对误差法、偏值、U图法、Y图法、趋势法等方法进行。故障数度量是一种在工程上被广泛应 用的方法。此外,还可以通过比较不同数据集合所做出的中位线图形来评价模型预测的有效性。如果一个模型产生的曲线最接近于0,则该模型是最优的。而且,这种有效性测定方法有效地克服了规范化图形评价与具体软件项目之间的联系,保证了它的独立性。 用给定可靠性数据对软件可靠性模型进行比较时,必须考察拟合模型与观察数据的一致 性和符合性。当然,根据拟合模型进行采样,是否可以获得足够的观察数据非常重要。拟合优度检验是一种系统地表达并证明观察数据和拟合模型之间全局符合性的方法,使用最广泛的是x2检验。 1.准确性 软件可靠性模型预测的准确性可用前序似然函数来测定。设观察到的失效数据对应于软 件相继失效之间的时间序列t1,t2,..,ti-1,并用这些数据来预测软件在未来可能的Ti,即希 望得到Ti的真实概率密度函数Fi(t)的最优估计值。假设以t1,t2,...,ti-1为基础预测Ti的 分布Fi(t)的概率密度函数 @@42D11000.GIF;表达式1@@ 对Ti+1,Ti+2,...,Ti+n的这种向前一步预测,即进行了n+1次预测之后的前序似然函数为 @@42D11001.GIF;表达式2@@ 由于这种度量常常接近于0,所以常用其自然对数进行比较。假定比较的两个软件可靠性 模型分别为A和B,则对它们进行n次预测之后的前序似然比为 @@42D11002.GIF;表达式3@@
设备软件可靠性测试 设备为达到连续可运行目标，除了在硬件设计中考虑器件可连续无故障运行外，很重要的方面是软件在各种条件下可经受考验，持续工作。这需要在实现基本功能前提下，在软件中设计一系列容错性逻辑去保证。 为全面评估软件容错性和故障恢复能力，测试需要制造或模拟一系列条件，包括内部硬件故障条件、外部恶意攻击条件、偶发过载条件、软件资源耗尽条件、周边环境故障条件以及长时间正常负荷持续运行模拟。为了在产品开发的不同阶段组织针对性测试，这些测试行为又被明确定义并归类。 测试分类 1、协议健壮性测试 协议健壮性测试是为了找出特定协议的具体实现代码的弱点。是一种以破坏性手段去尝试运行软件的行为，通过用户接口的异常输入，使用异常协议消息交互引导软件进入未定义或未保护的状态。 对软件系统而言，合法输入组合以外的输入往往超出正常输入的组合，软件运行中总会遇到一些预期之外的输入。因此，软件需要有严格的合法性检查才能避免进入未知状态。协议健壮行测试的目标就是尽可能找出软件保护不周的问题。 在软件测试的早期阶段进行的参数边界值测试就属于健壮性测试的一部分。比如一个用户接口接受1-100的整数输入，那么1和100就是合法边界，大于100和小于1的输入都是非法输入。其他非整数型的输入也属于非法值，包括故意破坏检查输入条件的代码的一些组合（如超长输入值，空输入，格式化字符等）。软件面对的接口除了最终用户可见的部分之外，还有大量的软件组件之间的不可见部分，以及设备之间的通信协议接口。 除了单一输入的简单合法性判断，软件在组合输入和特定状态下可接受输入的定义更为复杂。为确认软件在各种条件下的运行正常，测试需要尝试尽可能多的组合。复杂的通信协议除了定义有逻辑化结构的报文格式，还有一系列的内部状态，要测试人员完全手工方式遍历这些状态，并且构造所有可能的异常组合输入条件是无法想象的，因此需要专用的测试工具和仪器专门检测软件对各种协议变异报文的处理。目前，商用化的测试工具已经很多，比如IxDefend协议健壮性测试套件和MuDynamics的fuzzing测试套件是比较强大的。为了达成在特定状态下注入错误，测试套件需要先完成一些合法的交互过程，使被测目标达到预设状态，然后再注入异常。复杂的协议需要事先配置很多参数去达成这种交互，而变异输入的变化和组合数量非常庞大，一个复杂协议经常达到几十万甚至上百万的测试用例，尽管有自动化测试工具，这种测试运行也要耗费大量的时间。因此，对参数的调整是测试需要关注的一个重要方面。 从系统测试的角度，观测协议健壮性的测试结果是比较困难的，一般是从系统外部观察整机是否存在异常，正在被测试的协议功能有没有停止响应，正常用户请求是否得到及时处理，设备的性能有没有下降。最容易被观测到现象是系统死锁或重启，系统性能变化或主要功能异常也能被及时发现。而一些细微的功能异常或资源耗费，很容易被测试人员忽视，在这里，测试工具也无能为力。 以IxDefend测试TLS-Server举例。 完成测试仪器与被测试设备的物理连接，并且将端口配置IP地址，开启TLS-Server服务。 通过测试仪器的GUI控制界面装入TLS Server测试套件，。 配置TLS Server测试所需要的参数，包括被测试设备IP、TLS服务端口、超时时间等，。 点击开始按钮启动测试运行。
软件复杂度概述 在硬件的可靠性设计中，有一条基本原则“简单就是可靠”。这个原则同样也适合软件，与功能的增多或增强相伴的是不断升级与补丁。现在已经有若干种软件复杂性的度量方法可供参考，其中McCabe QA是比较出色和实用的方法，它能够计算出多种软件复杂度，由此可对软件进行检查、分析和查明那些可能导致错误的代码。 复杂度 70年代，软件系统已经变得极其复杂，无论是开发还是维护都是一项成本高昂的工作。人们意识到必须使软件模块化，以便于开发、测试和维护。为此，成立于1976的McCabe&Associates公司开发出了McCabe Cyclomatic Complexity Metric（圈复杂度）技术对软件进行结构测试。Metric以软件复杂度测量的数目为基础，能帮助工程师识别难于测试和维护的模块，圈复杂度已经成为评估软件质量的一个重要标准。人们可以用圈复杂度对软件的复杂度和质量进行衡量，来安排工程进度，在成本、进度和性能之间寻求平衡。 复杂度的种类 有模块、类和程序三类复杂度。模块复杂度包含了关于模块的复杂度信息；类复杂度是针对那些使用McCabe面向对象特性的程序，它包含了关于类的复杂度信息；程序复杂度包含了关于程序的复杂度信息。 集成复杂度报告 对应于三种复杂度的是三种复杂度报告。如果一个报告的复杂度信息不只一种，那么就把这些复杂度信息组合成新的报告。 集成复杂度信息只收集一个部件及其下级的信息。例如：如果一个程序级报告包含一个类复杂度，那么只报告组成程序的类的信息，而不包含类组成的信息。 McCabe复杂度 McCabe复杂度是对软件结构进行严格的算术分析得来的，实质上是对程序拓扑结构复杂性的度量，明确指出了任务复杂部分。McCabe复杂度包括：圈复杂度、基本复杂度、模块设计复杂度、设计复杂度、集成复杂度、行数、规范化复杂度、全局数据复杂度、局部数据复杂度、病态数据复杂度。 McCabe复杂度的用途 在软件工程中，有三种使用McCabe复杂性度量的方式。 作为测试的辅助工具。McCabe复杂性度量的结果等于通过一个子程序的路径数，因而需要设计同样多的测试案例以覆盖所有的路径。如果测试案例数小于复杂性数，则有三种情况一是需要更多的测试；二是某些判断点可以去掉；三是某些判断点可用插入式代码替换。 作为程序设计和管理指南。在软件开发中，需要一种简单的方式指出可能出问题的子程序。保持子程序简单的通用方法是设置一个长度限制，例如50行或2页，但这实际上是在缺乏测试简明性的有效方法时无可奈何的替代方法。不少人认为McCabe度量就是这样一种简明性度量。但是要注意，McCabe度量数大的程序，不见得结构化就不好。例如，Case语句是良结构的，但可能有很大的McCabe度量数（依赖于语句中的分支数），这可能是由于问题和解决方案所固有的复杂性所决定的。使用者应当自己决定如何使用McCabe度量所提供的信息。 作为网络复杂性度量的一种方法。Hall和Preiser提出了一种组合网络复杂性度量，用于度量可能由多个程序员组按模块化原理建立的大型软件系统的复杂性。他们提出的组合度量公式为 式中C1,...,Ck是各个模块的复杂性；CN是网络复杂性；W1和W2为权值。 McCabe复杂度即可用于度量各个模块的复杂性，也可用于度量网络复杂性。
可靠性定义及其度量指标 【大纲考试内容要求】： 1、了解机械失效三个阶段和维修度、有效度、平均无故障工作时间； 2、熟悉可靠性、故障率、可靠性预计、人机界面设计要点。 【教材内容】： 第四节机械的可靠性设计与维修性设计 一、可靠性定义及其度量指标 (一)可靠性定义 所谓可靠性是指系统或产品在规定的条件和规定的时间内，完成规定功能的能力。 这里所说的规定条件包括产品所处的环境条件(温度、湿度、压力、振动、冲击、尘埃、雨淋、日晒等)、使用条件(载荷大小和性质、操作者的技术水平等)、维修条件(维修方法、手段、设备和技术水平等)。在不同规定条件下，产品的可靠性是不同的。 规定时间是指产品的可靠性与使用时间的长短有密切关系，产品随着使用时间或储存时间的推移，性能逐渐劣化，可靠性降低。所以，可靠性是时间的函数。这里所规定的时间是广义的，可以是时间，也可以用距离或循环次数等表示。 (二)可靠性度量指标 1．可靠度 可靠度是可靠性的量化指标，即系统或产品在规定条件和规定时间内完成规定功能的概率。可靠度是时间的函数，常用R(t)表示，称为可靠度函数。 产品出故障的概率是通过多次试验中该产品发生故障的频率来估计的。例如，取N个产品进行试验，若在规定时间t内共有Nf(t)个产品出故障，则该产品可靠度的观测值可用下式近似表示：R(t)≈[N—Nf(t)]／N (4—7) 与可靠度相反的一个参数叫不可靠度。它是系统或产品在规定条件和规定时间内未完成规定功能
的概率，即发生故障的概率，所以也称累积故障概率。 不可靠度也是时间的函数，常用F(t)表示。同样对N个产品进行寿命试验，试验到瞬间的故障数为Nf(t)，则当N足够大时，产品工作到t 瞬间的不可靠度的观测值(即累积故障概率)可近似表示为： F(t)≈Nf(t)／N (4—8) 可靠度数值应根据具体产品的要求来确定，一般原则是根据故障发生后导致事故的后果和经济损失而定。 2．故障率(或失效率) 故障率是指工作到t 时刻尚未发生故障的产品，在该时刻后单位时间内发生故障的概率。故障率也是时间的函数，记为γ(t)，称为故障率函数。 产品的故障率是一个条件概率，它表示产品在工作到t 时刻的条件下，单位时间内的故障概率。它反映t 时刻产品发生故障的速率，称为产品在该时刻的瞬时故障率且γ(t)，习惯称故障率。故障率的观测值等于N个产品在t时刻后单位时间内的故障产品数△Nf(t)／△t与在t时刻还能正常工作的产品数Ns(t)之比，即： γ(t)＝△Nf(t)／[Ns(t)·△t] (4——9) 故障率(失效率)的常用单位为(1／106h)。 产品在其整个寿命期间内各个时期的故障率是不同的，其故障率随时间变化的曲线称为寿命的曲线，也称浴盆曲线，如图4—6所示。 由图可见，产品的失效过程可分为以下3个阶段：
11.1概述 11.1.1 软件质量的定义 软件质量定义为： (1)与所确定的功能和性能需求的一致性。 (2)与所成文的开发标准的一致性。 (3)与所有专业开发的软件所期望的隐含特性的一致性。 11.1.2 软件质量的度量和评价 影响软件质量的因素可以分为两大类： (1)可以直接度量的因素，如单位时间内千行代码（KLOC）中产生的错误数。 (2)只能间接度量的因素，如可用性或可维护性。 在软件开发和维护的过程中，为了定量地评价软件质量，必须对软件质量特性进行度量，以测定软件具有要求质量特性的程度。
11.1.3 软件质量保证 1. 什么是软件质量保证 软件的质量保证就是向用户及社会提供满意的高质量的产品，确保软件产品从诞生到消亡为止的所有阶段的质量的活动，即确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动。 2. 质量保证的策略 质量保证策略的发展大致可以分为以下三个阶段： (1)以检测为重。产品制成后才进行检测，这种检测只能判断产品的质量，不能提高产品质量。 (2)以过程管理为重。把质量保证工作重点放在过程管理上，对制造过程的每一道工序都进行质量控制。 (3)以新产品开发为重。 3. 质量保证的主要任务 (1)正确定义用户要求。 (2)技术方法的应用。 (3)提高软件开发的工程能力。 (4)软件的复用。 (5)发挥每个开发者的能力。 (6)组织外部力量协作。
(7) 排除无效劳动。最大的无效劳动是因需求规格说明有误、设计有误而造成的返工。 (8) 提高计划和管理质量。 4. 质量保证与检验 软件质量必须在设计和实现过程中加以保证。 11.2 质量度量模型 11.2.1McCall质量度量模型 这是McCall等人于1979年提出的软件质量模型。针对面向软件产品的运行、修正、转移，软件质量概念包括11个特性，其定义如下： (1)面向软件产品操作。 (2)面向软件产品修改。 (3)面向软件产品适应。 11.2.2 ISO的软件质量评价模型 软件质量度量模型由三层组成。 11.3 软件复杂性 11.3.1 软件复杂性的基本概念 软件复杂性度量的参数很多，主要有： (1)规模，即总共的指令数，或源程序行数。 (2)难度，通常由程序中出现的操作数的数目所决定的量来表示。 (3)结构，通常用于程序结构有关的度量来表示。 (4)智能度，即算法的难易程度。 软件复杂性主要表现在程序的复杂性。程序的复杂性主要指模块内程序的复杂性。它直接关联到软件开发费用的多少、开发周期长短和软件内部潜伏错误的多少。同时它也是软件可理解性的另一种度量。
软件质量指标度量 1综述 (2) 1.1编写目的 (2) 1.2阅读指南 (2) 2软件质量指标 (3) 2.1需求功能点覆盖率 (3) 2.2用例执行覆盖率 (3) 2.3缺陷修复率（截至于**年*月*日） (4) 2.4缺陷遗留个数（截至于**年*月*日） (4) 2.5缺陷分布统计（模块缺陷率） (4) 2.6缺陷分布统计（严重缺陷率） (5) 2.7缺陷密度及收敛 (5) 3测试过程质量指标 (8) 3.1缺陷探测率 (8) 3.2有效缺陷率 (8) 3.1用例执行效率 (9) 3.2缺陷发现率 (9) 4交付质量指标 (11) 4.1加载回退率 (11) 4.2故障回退率 (11) 5版本说明 (12)
1综述 1.1编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析，为当期被测产品的质量提供可参考的数据，也为后续测试提供数据的基础积累，并作为制定方法流程的依据。 1.2阅读指南 ●软件测试质量指标主要针对研发项目、商务项目被测产品出具数据 度量。 ●测试过程质量指标主要为测试经理、测试组长对测试人员的测试执 行质量出具数据度量。 ●交付质量主要为新需求的交付质量出具数据度量。 三者可单独使用，也可结合使用。
2软件质量指标 2.1需求功能点覆盖率 【需求覆盖率】：计算测试用例总数之和除以与之一一对应的功能点数之和，主要查看是否有功能点遗漏测试的情况。 【公式】：∑测试用例数（个） / ∑功能点（个） 说明：用例覆盖需求矩阵，一个需求对应多个功能点。 【数据来源】：《联通集中集团客户业务支撑系统销售管理用户需求说明书》《联通集中集团客户业务支撑系统销售管理需求跟踪矩阵》 【计算结果】需求覆盖率=113/8=14.13 2.2用例执行覆盖率 【用例执行覆盖率】：计算测试用例执行总数除以与之一一对应的测试数之和，主要查看是否有测试用例执行遗漏或有效的情况。 【公式】：∑执行的测试用例个数（个） / ∑测试用例个数（个）*100% 【数据来源】：《iSMS测试进度跟踪表》 【计算结果】：用例执行覆盖率=100%
标识： RMS-SRDT-{S Y1514127, SY1514207}-BG-V1.0-2015 ATM软件 可靠性验证测试实验报告 北航可靠性与系统工程学院 二〇一五年十二月
ATM软件 可靠性验证测试实验报告 编写：林烨 (SY1514127)日期:12月31日校对：王洋洋(SY1514207)日期:12月31日
目录 1 软件可靠性验证测试要求 (1) 1.1 软件可靠性验证测试统计方案 (1) 1.2 软件失效的定义 (1) 1.3 软件可靠性验证测试终止条件 (1) 2 测试结果 (2) 2.1 测试用例生成情况 (2) 2.2 测试用例执行情况 (2) 3 软件可靠性验证测试结论 (3) 4 软件可靠性点估计和区间估计 (4) 5 软件可靠性验证测试实验总结与建议 (4)
1软件可靠性验证测试要求 1.1软件可靠性验证测试统计方案 软件可靠性验证测试常用的统计方法有定时结尾、贯序截尾和无失效结尾三种。序贯截尾试验事先对试验总时间及试验所需用资源无法确定，只能根据事先拟定的接收、拒收条件结束试验，无法估计MTBF的真值，但是为了更充分地利用软件每次的失效信息，以及在可靠性比较高或比较低的情况下可以做出更快的判决，我们采用序贯验证测试。选取的序贯测试方案参数为：生产方风险（α）：10%，使用方风险（β）：10%，鉴别比（d）：1.5，MTBF最低可接受值：600s。生成序贯曲线如图1所示。 图1 序贯验证测试曲线图 1.2软件失效的定义 软件不能实现软件需求规格说明书上的功能。 1.3软件可靠性验证测试终止条件 当有点落到接受区或拒绝区时终止测试。
软件可靠性工程 1.软件可靠性定义 1.1.广义 是指一切旨在避免、减少、处理、度量软件故障（错误、缺陷、失效）的分析、设计、测试等方法、技术和实践活动。于是有诸多相关术语，如软件可靠性度量、软件可靠性设计、软件可靠性建模、软件可靠性测试、软件可靠性管理等。 1.2.狭义 指软件无失效运行的定量度量，尤其是那些面向用户的定量度量。主要有： ?软件可靠度：表示软件在规定的运行环境中和规定的运行时间内无失效运行的机 会。软件无失效运行的机会多以概率度量，但也可以模糊数学中的可能性加以度量，有时也在数据域上将软件可靠度表示为软件成功执行一个回合的概率。 ?软件失效强度：其物理解释是单位时间内软件发生失效的机会。在概率范畴内，它 与软件可靠度有明确的数学关系（R(t)＝1－F(t)，R(t)为可靠度，F(t)为失效强度）。 ?软件平均失效时间（MTTF）：表示软件投入运行到出现一个新失效的时间。 上述度量与硬件可靠性中的相应概念本质上是一致的。 “失效”是指程序的功能在某方面没有达到用户的需求。“没有像用户需求的那样工作”是一个很广的定义。因此，可靠性结合了与程序执行相关联的所有属性。例如，它包括正确性、安全性和可使用性的操作方面，以及对用户的友好性。请注意，安全性实际上是软件可靠性的一个特殊子类。 可靠性不包括可移植性、可修改性或文档的可理解性。
可靠性是面向用户的而不是面向开发人员的。可靠性与操作有关，而不是与程序的设计有关，因此可靠性是动态的，而不是静态的。可靠性考虑问题出现的频率，直接与操作经验和在经验中错误的影响相关。因此，可以很容易地将可靠性与成本联系起来。可靠性很适合检查发展趋势的重要性、设定目标和预测什么时候可以达到目标。可靠性使人们可以使用同样的术语对硬件和软件的系统可靠性进行分析，而在真实系统中硬件和软件都同时存在。所以，可靠性度量比错误度量要有用得多。 2.软件可靠性工程的研究范围 软件可靠性工程涉及以下四方面活动和有关技术： 2.1.软件可靠性分析 进行软件可靠性的需求分析、指标分配、故障树分析、失效模式和影响分析、软件开发过程中有关软件可靠性的的特性分析、……等。 2.2.软件可靠性设计和实现 进行防错设计、容错设计、检错设计、纠错设计、故障恢复设计、软件可靠性增长、……等。 2.3.软件可靠性测量、测试和评估 在软件生存周期各阶段进行有关软件可靠性设计、制造和管理方面的属性测量，进行基于软件运行剖面的测试用例随机输入的软件测试、软件可靠性预计、软件可靠性估计、软件可靠性验证、……等。 2.4.软件可靠性管理 确定影响软件可靠性的因素，制定必要的设计和实现准则以及对软件开发各阶段软件可
北京语言大学网络教育学院 《软件工程》模拟试卷一 注意： 1.试卷保密，考生不得将试卷带出考场或撕页，否则成绩作废。请监考老师负责监督。 2.请各位考生注意考试纪律，考试作弊全部成绩以零分计算。 3.本试卷满分100分，答题时间为90分钟。 4.本试卷分为试题卷和答题卷，所有答案必须答在答题卷上，答在试题卷上不给分。 一、【单项选择题】(本大题共15小题，每小题2分，共30分)在每小题列出的四个选项中只有一个选项是符合题目要求的，请将正确选项前的字母填在答题卷相应题号处。 1、在软件开发领域中，“描述了实现概念模型的软件解决方案”的系统模型被称为（ B ）。 [A] 设计模型[B] 软件模型[C] 实现模型[D] 部署模型 2、一般来说，整个需求的主体是（ A ）。 [A] 功能需求[B] 性能需求 [C] 外部接口需求[D] 设计约束 3、总体设计的第二阶段是（ D ）。 [A] 初始设计[B] 详细设计[C] 复审阶段[D] 精化设计 4、在模块内聚类型中，常常通过研究流程图确定模块的划分，得到的是（ D ）。 [A] 逻辑内敛[B] 顺序内敛[C] 功能内敛[D] 过程内敛 5、一个模块直接控制(调用)的下层模块的数目称为模块的（ B ）。 [A] 扇入[B] 扇出[C] 深度[D] 宽度 6、UML术语中，限定符常被用在（ C ）。 [A] 依赖关系[B] 泛化关系[C] 关联关系[D] 细化关系 7、UML提供的13种图形化工具中，用于概念模型和软件模型静态结构的是（ C ） [A] 用况图[B] 状态图[C] 类图[D] 活动图 8、RUP的迭代、增量式开发规定的4个阶段不包括（ A ）。 [A] 评审阶段[B] 构造阶段[C] 移交阶段[D] 精化阶段 9、根据RUP实现的活动，输入为设计类，活动为实现类，则输出为（ D ）。 [A] 用况[B] 子系统[C] 接口[D] 构件 10、软件评估可分为静态评估和动态评估，其中属于动态评估技术的是（ D ）。 [A] 评审[B] 走查[C] 形式化证明[D] 软件测试 11、黑盒测试技术，又称为（ A ）。 [A] 功能测试[B] 结构测试[C] 系统测试[D] 集成测试 12、若有语句if(A<1 and C>0)then B=1／C else B=1／A，选用类似数据A=2，C=1；A=-2，C=1；A=2，C=-1；A=-2，C=-1；得到不同B的值，这种测试策略为（ C ）。