第7章-软件测试度量与评价

第7章软件测试度量与评价软件测试过程软件测试的目的发现软件缺陷和错误；对软件质量进行度量和评价；通过分析错误产生的原因还可以帮助发现开发工作所采用的软件过程的缺陷，以便进行软件过程改进。举例软件质量及度量软件质量需要度量质量包括哪些方面？如何获取这些质量数据？获取数据后如何做出度量？7.1什么软件质量GB/T11457（2006版）中软件质量是：（1）软件产品中能满足给定需要的性质和特性的总体。（2）软件具有所期望的各种属性的组合程度。（3）顾客和用户觉得软件满足其综合期望的程度（明确的、隐含的、实际中的实用需求）。（4）确定软件在使用中满足顾客预期要求的程度。狭义的质量定义，是指产品无缺陷，满足客户的需求；而广义的软件质量则包括产品质量、过程质量和客户满意度是否可以零缺陷？高质量的软件：约束下的高质量能够按照预期的时间和成本提交给用户，并能够按照预期要求正确工作的软件ScopeTimeCost范围

成本进度质量如何确认软件可以上线了：度量开发过程测试过程系统测试准备系统测试执行软件度量软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。没有软件度量，就不能从软件开发的暗箱中跳将出来。通过软件度量可以改进软件开发过程，促进项目，开发高质量的软件产品。软件度量软件的度量取向一般包括项目规模、项目成本、项目进度、顾客满意度、质量等度量，以及品牌资产度量、知识产权价值度量等。度量取向要依靠事实、数据、原理、法则；其方法是测试、审核、调查；其工具是统计、图表、数字、模型；其标准是量化的指标。软件质量及度量软件质量需要度量质量包括哪些方面？如何获取这些质量数据？获取数据后如何做出度量？7.2软件质量模型McCall质量模型Boehm质量模型ISO-9126质量模型人们通常把影响软件质量的特性用软件质量模型来描述。软件质量模型计算机界对软件质量的属性进行了较多的研究，得到了一些有效的质量模型，包括：McCall模型Boehm模型ISO9126模型McCall质量模型质量模型中的质量概念基于11个特性之上，这11个特性分别面向软件产品的运行、修正、转移。McCall质量模型*Boehm质量模型*8个质量特性，21个子特性ISO-9126质量模型外部测量内部质量属性外部质量属性使用质量属性内部测量使用质量的测量软件产品软件产品的效用使用条件影响影响依赖依赖软件质量包括3部分：“内部质量”、“外部质量”和“使用质量”。ISO-9126质量模型外部和内部质量功能性可靠性易用性效率维护性可移植性适合性准确性互操作性保密安全性功能性的依从性成熟性容错性易恢复性可靠性的依从性易理解性易学性易操作性吸引性易用性的依从性时间特性资源利用性效率的依从性易分析性易改变性稳定性易测试性维护性的依从性适应性易安装性共存性易替换性可移植性的依从性内部质量：

是从内部观点出发的软件产品特性的总体，是针对内部质量需求被测量和评价的质量。内部质量特征：

可维护性、灵活性、可移植性、可重用性、可读性、可测试性、可理解性等。ISO-9126质量模型外部质量：软件产品在规定条件下使用时满足需求的程度。它是从外部观点出发的软件产品特性的总体，当软件执行时，更典型地是使用外部度量在模拟环境中，用模拟数据测试时，所被测量和评价的质量，即在预定的系统环境中运行时可能达到的质量水平。外部质量特征：正确性、可用性、效率、可靠性、完整性、适应性、精确性、坚固性等。ISO-9126质量模型使用质量：在规定的使用环境下软件产品使特定用户在达到规定目标方面的能力。它是从用户观点出发，来看待软件产品用于特定环境和条件下的质量，反映的是从用户角度看到的软件产品在适当系统环境下满足其需求的程度。使用质量特征:有效性、生产率、安全性、满意程度等。ISO-9126质量模型软件质量及度量软件质量需要度量质量包括哪些方面？如何获取这些质量数据？获取数据后如何做出度量？V&V软件质量及度量软件质量需要度量质量包括哪些方面？如何获取这些质量数据？获取数据后如何做出度量？7.3测试测量与产品质量评估过程测试测量的目的测试测量过程软件通用评价过程覆盖评测质量评测测试测量的目的测试测量的目的是确认、搜集、分析和应用测试过程和正在开发的产品的数据，以支持一个组织对测试过程的效果和效率、测试人员生产率、产品质量、测试改进的结果进行客观评价。举例测试测量过程测试测量过程主要包括如下四个方面：（1）建立测试测量目标：我们为什么需要测量这个指标？（2）制定测试测量，测试测量指标包括基本指标和衍生指标，例如测试用例数的估计值和实际测量值、缺陷总数、严重级别的缺陷数或优先级高的缺陷数、缺陷发现率、缺陷密度、同行评审覆盖度、燃烧测量（如每周测试用例执行率）等。（3）指定数据搜集和存储规程：包括收集频率、数据采集点、存储数据的时间线和安全准则、相应的支持工具等。（4）指定分析规程，即明确分析方法、如何检查测试测量之间的关系、分析工具选择等。软件通用评价过程质量评估过程步骤产品质量评估过程可基于软件产品的通用评价过程进行。步骤：（1）识别产品质量需求产品质量需求可能来源于：需求规格、组织的产品质量目标、业务目标、市场调查、服务水平协议等。对于产品质量需求的完整性和优先级别需要在项目组织内进行评审并达成一致。明确评价目的，明确产品类型，在组织、客户和最终用户的需求基础上，建立产品的量化目标。（2）定义项目的量化产品质量目标依据软件产品质量模型，选择与明确产品的质量目标，例如产品的功能性、可靠性、可维护性、可用性、可移植性、效率等属性的目标，为每一个选定的产品质量属性定义量化产品目标，识别出可测量的数值。质量目标一般都作为项目的验收标准。质量评估过程步骤（3）定义测量项目产品质量目标的途径例如，为了测量产品质量，可能用到的技术包括同行评审、原型开发、静态（代码）分析、动态测试、预测（根据在开发测试期间的缺陷数量，以预测在生命周期后期发现的缺陷）等。（4）在整个生命周期内量化测量产品质量对项目交付的产品和工作产品的质量进行量化测量，对需求文档、设计文档、接口规范、原型、代码及独立组件等进行质量测试数据的收集，并保证数据的完整性和准确性。（5）分析产品质量测量，并将它们与产品的量化目标相比较。通过对产品质量测量数据的分析，和干系人对质量测量数据的沟通，识别并记录重大产品质量问题及其影响，并明确需要采取的纠正措施。学习几个测试测评指标：覆盖评测质量评测软件测试测评测试覆盖测评及质量测评测试覆盖评测是对测试完全程度的评测，它建立在测试覆盖基础上，测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的缺陷及缺陷修复的分析基础上。覆盖评测：覆盖评测指标是用来度量软件测试的完全程度的，所以可以将覆盖用做测试有效性的一个度量。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖，它们分别是指针对需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度评测。1、基于需求的测试覆盖基于需求的测试覆盖在测试过程中要评测多次，并在测试过程中，每一个测试阶段结束时给出测试覆盖的度量。例如，计划的测试覆盖、已实施的测试覆盖、已执行成功的测试覆盖等。基于需求的测试覆盖率通过以下公式计算：

测试覆盖率=T(p,i,x,s)/RfT%（T：已计划的、已实施的或成功的测试需求数，RfT：测试需求的总数）测试分析覆盖率=需要进行测试分析的功能需求数/被测系统总的功能需求数测试用例覆盖率=编写用例的测试需求点数/测试需求点的总数。测试用例执行覆盖率=实际执行用例数/设计总用例数2．基于代码的测试覆盖基于代码的测试覆盖评测是测试过程中已经执行的代码的多少，与之相对应的是将要执行测试的剩余代码的多少。

许多测试专家认为，一个测试小组在测试工作中所要做的最为重要的事情之一就是度量代码的覆盖情况。基于代码的测试覆盖率通过以下公式计算：基于代码的测试覆盖率=Ie/TIic%其中：Ie是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行代码数。TIic是代码的总数。

很明显，在软件测试工作中，进行基于代码的测试覆盖评测这项工作极有意义，因为任何未经测试的代码都是一个潜在的不利因素。在一般情况下，代码覆盖运用于较低的测试等级（例如单元和集成级）时最为有效。但是，仅仅凭借执行了所有的代码，并不能为软件质量提供保证。也就是说，即使所有的代码都在测试中得到执行，并不能担保代码是按照客户需求和设计的要求去做了。质量评测：测试覆盖的评测提供了对测试完全程度的评价，而在测试过程中对已发现缺陷的评测提供了最佳的软件质量指标。缺陷分析通常用以下4类形式的度量提供缺陷评测：缺陷发现率；缺陷潜伏期；缺陷密度。整体软件缺陷清除率缺陷分析相关指标1．缺陷发现率缺陷发现率是将发现的缺陷数量作为时间的函数来评测，即创建缺陷趋势图。2、阶段缺陷清除率（DRE）评审和测试是重要的清除活动。详细设计阶段DRE=100/[(69+129+500)-(35+68)]*100%=17%系统测试阶段DRE=195/[(69+129+500+393)-(35+68+100-415-230)]*100%=80%考察编码阶段的缺陷清除率时，这个阶段包含了两个缺陷清除活动：单元测试和代码评审。可以考察其中一个活动的缺陷清除率，也可以对编码阶段的这两个活动合起来考察，那么编码阶段的缺陷清除率应该为：(415+230)/[(69+129+500+393)-(35+68+100)]*100%=73%3．缺陷密度软件缺陷密度是一种以平均值估算法来计算出软件缺陷分布的密度值。程序代码通常是以千行为单位的，软件缺陷密度是用下面公式计算的：下图显示了一个项目的各个模块中每千行代码的缺陷密度。各个模块中每千行代码的缺陷密度但是，在实际评测中，缺陷密度这种度量方法是极不完善的，度量本身是不充分的。这里边存在的主要问题是：所有的缺陷并不都是均等构造的。各个软件缺陷的恶劣程度，及其对产品和用户的影响的严重程度，以及修复缺陷的重要程度有很大差别，有必要对缺陷进行“分级、加权”处理，给出软件缺陷在各严重性级别或优先级上的分布作为补充度量，这样将使这种评测更加充分，更有实际应用价值。指标名称指标说明计算公式/分析方法目标值权重数据来源系统测试覆盖率判断设计的测试用例是否完备系统测试用例设计所覆盖功能点数/系统功能点总数95%20%测试需求跟踪表注：系统功能点数，也可采用如UseCase数、代码规模等其他规模统计方式。测试执行率判断测试执行的完备性已执行的测试用例数/设计的总测试用例数83%20%测试用例、测试用例执行结果编码质量指标判断是否发现了足够数量的缺陷缺陷数（缺陷严重等级为“次要”以上的缺陷）/规模8个/KLOC15%项目估算表、缺陷库注：这里“规模”采用KLOC为单位，也可采用UseCase数或者是功能点数等其他规模统计方式。缺陷解决率判断是否解决了必须的缺陷，只有少数非致命、严重的缺陷允许遗留关闭缺陷数/总缺陷数（前提：状态为“非关闭”的“严重级别”为致命、严重缺陷数=0）91%20%缺陷库缺陷收敛趋势用于判断质量趋势，间接评价产品是否可对外发布使用发现缺陷与关闭缺陷两条趋势曲线。期望发现缺陷与关闭缺陷曲线汇集，并持续了一段时间，此时产品质量比较稳定，可以批准对外发布。期望发现缺陷与关闭缺陷曲线汇集，并持续了两轮测试25%缺陷库版本上线度量指标及相应的权重样例7.4软件测试度量指标什么是软件测试度量？什么基础度量&衍生度量？如何进行测试度量？总结一下软件测试度量的5W1HWhyWhatwhereWhenwhohowwhy软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。测试度量的目的是确认、搜集、分析和应用测试过程和正在开发的产品的数据，以支持一个组织对测试过程的效果和效率、测试人员生产率、产品质量、测试改进的结果进行客观评价。what软件的度量取向一般包括项目规模、项目成本、项目进度、顾客满意度、质量等度量，以及品牌资产度量、知识产权价值度量等。度量取向要依靠事实、数据、原理、法则；其方法是测试、审核、调查；其工具是统计、图表、数字、模型；其标准是量化的指标。一个测试度量方案有两个核心方面：支持测试过程和产品质量评估、支持过程改进。where&when&who测试阶段：单元测试、集成测试、系统测试、验收测试测试执行：测试需求完整性、测试用例执行情况、测试缺陷及分布情况how（1）制定测试度量指标，包括基本指标和衍生指标，例如测试用例数的估计值和实际测量值、缺陷总数、严重级别的缺陷数或优先级高的缺陷数、缺陷发现率、缺陷密度、同行评审覆盖度、燃烧测量（如每周测试用例执行率）等。（2）指定数据收集和存储规程：包括收集频率、数据采集点、存储数据的时间线和安全准则、相应的支持工具等。（3）指定分析规程，即明确分析方法、如何检查测试测量之间的关系、分析工具选择等。基础度量&衍生度量注：衍生度量有时又称为派生度量。度量数据收集度量表样例日期迭代版本总用例数已执行用例数用例执行率有效缺陷总数已解决缺陷数未解决缺陷数缺陷解决率2020/10/26V779810112.7%3082226.7%2020/10/27V780412115.0%42113126.2%2020/10/28V781015018.5%54153927.8%2020/10/29V781621025.7%66214531.8%2020/10/30V782227032.8%78275134.6%2020/11/2V782833039.9%90355538.9%2020/11/3V783439046.8%102426041.2%2020/11/4V784045053.6%114585650.9%结合图形分析实例展示实例7.5软件缺陷管理及缺陷预防软件缺陷和软件缺陷种类软件缺陷的属性软件缺陷跟踪软件缺陷严重级别软件缺陷提交方法软件缺陷和软件缺陷种类软件缺陷的定义和描述：软件缺陷简单说就是存在于软件（文档、数据、程序）之中的那些不希望，或不可接受的偏差，而导致软件产生的质量问题。按照一般的定义，只要符合下面5个规则中的一个，就叫做软件缺陷：软件未达到软件规格说明书中规定的功能；软件超出软件规格说明书中指明的范围；软件未达到软件规格说明书中指出的应达到的目标；软件运行出现错误；软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。单一准确可以再现完整统一短小简练特定条件补充完善不作评价软件缺陷的有效描述规则（1）缺陷标识（2）缺陷描述与缺陷注释（3）缺陷类型（4）缺陷严重程度级别（5）缺陷产生可能性（6）缺陷的优先级（7）缺陷状态（8）软件缺陷的起源（9）软件缺陷的来源（10）缺陷根源软件缺陷的属性软件缺陷的生命周期软件缺陷从被测试人员发现一直到被修复，也经历了一个特有的生命周期的阶段。下面是一个最简单的软件缺陷生命周期的例子，系统地表示软件缺陷从被发现起经历的各个阶段：（1）测试人员找到并登记软件缺陷，软件缺陷被移交到程序修复人员。（2）程序修复人员修复软件中的软件缺陷，然后移交到测试人员。（3）测试人员确认软件缺陷被修复，关闭软件缺陷。实例：

缺陷流转流程

（缺陷生命周期）New(新缺陷)：测试中新发现的软件缺陷（bug）；Open(打开)：由开发人员确认是缺陷；Fixed(修正)：开发人员已完成修正，等待测试人员验证；Rejected(拒绝)：由于测试人员对某功能项理解不足产生的不是缺陷的问题，经开发人员提出，并由测试人员确认的不是缺陷的问题；Deferred(延期):不在回归测试版本修复的错误，下一版或以后再修复的缺陷；Closed(关闭)：复测后，确认的已被修复的缺陷；Reopen(重开)：开发人员已修改，但测试人员回归测试后发现依然存在的缺陷；Pending（未决的）：开发方确认是缺陷，但需要进一步和客户确认后再决定是否修改的缺陷。实例：缺陷状态缺陷流转流程说明步骤描述1测试人员提交新的Bug入库，缺陷状态为New。2开发人员验证缺陷，如果确认是缺陷并将分配给开发人员解决，设置其状态为Open，同时将其分配给相应的开发人员修改；若有些缺陷是需要进一步与客户确认后，再决定是否修改的，置状态为Pending。3开发人员认为不是缺陷、不能重现或对缺陷报告有疑问的，定期与测试人员沟通，测试人员负责重现BUG，如果是缺陷，则由开发人员置状态为open，如果测试人员确认不是缺陷，则由测试人员则置状态为Rejected，如果还不能明确问题，由开发和测试双方人员讨论，最后决定BUG的状态。4开发人员查询状态为Open的Bug，在开发环境进行修改，并在对应的BUG下记录修复说明，如果完成修复则置状态为Fixed。每一轮测试（除第一轮外）发布新版本后，开发组需要将已修改的需要测试人员复测的缺陷，均置为Fixed状态。5对于不能解决和延期解决的Bug，要留下文字说明，由开发组置为Deferred。6测试人员在新一轮回归测试时，查询状态为Fixed的Bug，然后验证Bug是否已修复，如修复,则置Bug的状态为Closed，如没有修复则置状态为Reopen。7每一轮结束之前，应把所有状态为New的BUG进行评审确认，使QC库不再有状态为New的BUG，本轮方可结束。8对于缺陷级别有不同意见，应由客户方和测试方协商后，决定升级还是降级。缺陷严重程度定义一般分为3级到5级，如下样例，bug严重等级为4个级别：严重等级缺陷判定准则致命缺陷导致系统crash、上线后可能导致无法进行正常业务、用户数据受到破坏、系统数据完全混乱无法再继续进行测试、任何一个主要功能完全缺失或丧失、主要进程死锁等。严重缺陷系统主要功能部分缺失或丧失、任何一个次要功能完全缺失或丧失、影响客户账务正确性、影响银行会计账务正确性、多个业务无法正确执行且无绕行方式、外部重要接口无法联通或内容错误而影响业务完成、功能设计不对而导致业务无法正确完成、系统性能表现不符合设计要求、系统所提供的功能或服务受到明显的影响等。一般缺陷系统辅助、支持类功能缺失、实现不正确或无法使用，但不影响业务流程中其他功能测试的缺陷。错误功能导致主要业务无法正确执行且暂时有绕行方式、客户回单/对账单等重要凭证内容错误、有关重要业务信息的页面回显错误、非重要数据错误等。轻微缺陷功能实现基本正确，但在表达方面不符合行业规范或不利于使用的缺陷。错误功能导致次要业务无法正确执行但暂时有绕行方式、统计类业务报表格式错误、客户回单/对账单等重要凭证内容有瑕疵，虽不影响业务进行，但影响客户满意度。改进建议系统整体风格以及使用习惯等的改进建议。虽然是功能错误但不属于上线需要的业务功能问题。使用不便等修饰性问题，或对系统使用的确认问题，界面不够友好性或界面造成客户使用不便的问题等缺陷级别（严重等级）如下样例，bug严重等级为5个级别：提交缺陷时，要求测试人员逐一注意如下问题：（1）每个步骤只记录一个操作，保证简洁、条理井然；（2）步骤完整、准确、简短，保证快速准确的重复缺陷。“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤；（3）对于有特殊测试数据的情况，需要在测试步骤中说明使用的数据，有助于缺陷的重现与定位；（4）选择相应的属性值，例如：缺陷类型等、缺陷级别等；（5）每条缺陷只包括一个错误；（6）根据需要，将缺陷截图作为附件保存在缺陷附件中。提交测试缺陷注意事项软件缺陷的再现确保所有的步骤都被记录注意时间和运行条件上的因素注意软件的边界条件注意事件发生次序导致的软件缺陷考虑资源依赖性和内存、网络、硬件共享的作用不要忽视硬件软件测试人员需正确面对软件缺陷在软件测试过程中，软件测试人员必须确保测试过程发现的软件缺陷得以关闭（生命周期跟踪）。软件测试人员需要从综合的角度考虑软件的质量问题，对找出的软件缺陷保持一种平常心态。1.并不是测试人员辛苦找出的每个软件缺陷都是必须修复的有些软件缺陷不被修复的原因如下。（1）没有足够的时间（2）不算真正的软件缺陷（3）修复的风险太大（4）不值得修复2.发现的缺陷的数量说明不了软件的质量3.不要指望找出软件中所有的缺陷实例：缺陷提交规范（1）1、<标题>：要求用简洁的文字描述出所提交的bug。建议在标题中写明模块或菜单名，这样将有助于开发人员更快的定位该bug，和有助于开发人员的bug分配；2、<详细信息>中，红色字段为必填项，黑色为非必填项。其中，“实际修复版本”当有缺陷关闭时，即置为closed时，必须填写，这样有助于对缺陷情况的跟踪；缺陷提交规范（2）3、<描述>：（1）实际结果的描述很重要，目的是把缺陷描述清楚。实际结果中，除了描述出实际与预期的和不同外，还需要把测试数据或重要的ID等写在实际结果中，这样有助于开发人员对缺陷的复现和问题的定位（2）若用例的操作步骤等没有描述仔细，需要在缺陷描述中细化（3）测试人员在提交某操作员代码及重要ID号（如报案号）的缺陷后，最好暂时不要用该条数据做后续操作，待开发人员确认该缺陷后（置为open等），方可继续使用该数据做后续操作（4）对于文字不能充分说明的缺陷，根据缺陷的情况，可以利用附图或附加录像的方法，进一步阐述，总之目的是把缺陷描述清楚缺陷提交规范（3）4、<注释>的使用：用于测试人员、开发人员、测试管理人员对该bug的一些说明的记录。对于某个Rejected的缺陷，开发人员必须在“注释”中填写原因；对于Reopen的缺陷，测试人员需要在注释中，把复测后存在的问题再次描述。缺陷提交规范（5）缺陷类型定义标准代码类问题技术架构设计有缺陷；功能模块架构设计有缺陷;解决方案设计有缺陷；代码开发有缺陷；配置类问题配置类问题（程序系数配置错误，IP地址配置错误）环境类问题测试环境相关问题，如数据库不可用，网络连接，系统异常，及批处理执行导致各系统状态不一致等测试环境相关的问题迁移类问题迁移机制，迁移规则等迁移相关的问题接口类问题系统间接口的缺陷参数类问题参数配置类的问题需求类问题需求不清晰导致的缺陷其他其他类问题实例：缺陷来源定义表缺陷类型定义标准非缺陷测试人员提交的不是缺陷，而是测试人员对需求的理解有误，或操作性问题。需求类缺陷需求变更，需求不清楚，需求不完整，不正确，需求缺陷等需求相关问题。信息提示类缺陷错误提示信息不符合架构组的规定，或无法理解的问题功能类缺陷交易的功能性错误，交易提交失败，不符合预期结果等参数类缺陷

参数设置未生效、参数配置错误、参数设置不完整/不准确等参数相关的问题数据类缺陷数据迁移错误、老数据与新系统不兼容等数据类问题。打印类缺陷凭证打印中打印信息的调整、打印凭证数据的错误等打印凭证问题账务类缺陷会计科目错误、会计核算金额的不正确、会计记账错误等会计核算类问题；性能类缺陷处理速度慢，由于文件的大小，内存等原因造成系统崩溃接口类缺陷系统与系统之间接口不一致或者处理错误导致的问题其他其他类问题实例：缺陷类型定义