软件质量度量指标v1.0
D_基于功能点分析法(FPA)的度量体系建设简析V1.0-田代军
基于功能点分析法（FPA）的度量体系建设简析随着信息技术的发展和应用系统规模的增大，无论是系统的建设方还是承建方，都迫切需要建设组织自身的数据度量体系，以便加强项目过程控制、提高生率、降低生产成本，提升市场竞争优势。
组织要建设适合自身需要的度量体系，首先要确定度量所采用的工具和方法，其次要确定度量的要素，即要度量哪些数据，然后建设可信的度量数据库，最后根据度量的数据进行分析，持续改进过程绩效。
以下通过某组织的基于功能点分析法的度量库建设实践，对建设度量体系的基本过程简述如下：1、采用功能点分析法（FPA）功能点分析法具有30多年的发展历史，是由IBM的工程师Allan Albrecht在1984年第一个公开发布了用于软件功能规模度量的功能点分析方法。
1986年国际功能点用户组（IFPUG）成立以来，其不断增强软件功能规模度量的Albrecht方法，现已形成了功能点度量方法的国际标准，即ISO/IEC 20926《IFPUG功能规模度量方法》。
该标准规定了详细功能点度量方法，其是从用户的角度识别数据功能（ILF内部逻辑文件和EIF外部接口文件）和事务功能（EI外部输入/EQ外部查询/EO外部输出），通过计算其复杂度并结合14个调整因子,得出估算的功能点数（即软件规模数据）。
NESMA（荷兰软件度量协会）对功能点度量方法进行了改进，形成了国际标准ISO/IEC 24570《功能点分析应用定义和计数指南》。
该标准指出，在不同的需求阶段，采用不同的估算参数，比如在产品初期阶段，需求尚未完全明确以及拆分，FPA中只计数ILF 和ELF 数据文件数即可初步获得软件规模。
计算规则如下：总体UFP（未调整功能点）=35xILF+15xELF；在系统需求逐步明确后，则采用估算功能点方法计算功能点。
计算规则如下：总体UFP（未调整功能点）=10xILF+7xELF+4xEI+5xEO+4xEQ。
北京软件造价评估技术创新联盟（以下简称“联盟”）推出的计算规则，就是基于以上两种场景下的估算功能点方法，通过相应的调整因子，计算出调整后的应用系统的功能点数。
软件测试的质量度量与指标
软件测试的质量度量与指标在软件开发和应用过程中，软件测试是一个至关重要的环节，它可以发现和减少软件中的缺陷和错误，提高软件的质量和可靠性。
然而，要评估软件测试的有效性和质量，就需要使用一些度量指标来衡量。
本文将讨论软件测试的质量度量与指标。
1. 缺陷密度缺陷密度是衡量软件测试质量的一个重要指标，它表示在一定代码行数或功能点数中存在的缺陷数量。
缺陷密度越低，说明软件质量越高。
通过度量每个阶段或每个版本中的缺陷密度，可以了解软件质量的变化趋势，并及时采取措施进行修复。
2. 测试覆盖率测试覆盖率是衡量软件测试覆盖面的指标，它表示对软件功能和代码逻辑的测试是否全面。
常见的测试覆盖率包括语句覆盖率、分支覆盖率和路径覆盖率等。
测试覆盖率越高，说明测试用例覆盖了更多的功能和代码路径，提高了对软件缺陷的发现能力。
3. 故障转化率故障转化率是指测试中发现的缺陷在软件发布后被用户报告的比例。
这个指标反映了测试工作中发现的缺陷是否能够有效地防止在用户环境中发生。
如果故障转化率较低，说明测试工作有效，质量控制较好。
4. 回归测试效率回归测试是在软件进行修改或升级后重新执行旧的测试用例，以确认旧功能是否正常工作和新功能是否引入了新的问题。
回归测试效率是指在一定的时间内执行的回归测试用例数量，用于评估测试团队的效率和测试环境的稳定性。
回归测试效率越高，说明测试团队能够更快地发现和修复问题。
5. 可靠性可靠性是指软件在一定时间内正常运行的能力，是衡量软件质量的重要指标之一。
通过统计软件的平均无故障时间间隔（MTTF）和平均故障时间（MTBF），可以评估软件的可靠性。
较高的可靠性意味着软件的质量较好，用户可以放心地使用。
6. 效率效率是指软件在完成特定任务时所需的时间和资源消耗。
通过度量软件测试的效率，可以评估测试团队的效能和测试工具的性能。
效率高的测试过程可以节省时间和成本，提高软件开发和发布的效率。
7. 用户满意度用户满意度是衡量软件测试质量的关键指标之一。
软件部绩效管理考核标准规范
软件部绩效考评方案第一部分、考评对象研发全体人员第二部分、工作职责一、项目经理和用户方对接需求，合理分配内部资源，统筹所负责项目标整体计划，监控跟踪开发过程进度，着手处理棘手问题，并应对突发情况对项目整体计划做出调整。
二、开发人员（程序员、中级程序员、高级程序员）依据需求文档，在项目经理任务划分负责范围内，按效率天天完成固定功效编码工作，并负担该部分维护工作。
三、测试人员按指定文档编写测试用例，并对相关项目进行单元，集成及系统测试工作。
四、美工人员负责直接和用户沟通UI方面相关业务，并针对所负责项目标软件交互进行美术及交互设计,并按需切图，关键输出产物为牵引图，UI指导，拓展图，PSD原图，及切图。
第三部分、开发及测试人员考评内容（初，中，高）一、质量考评1. 度量指标质量度量关键是依据度量指标来进行评价；质量指标是指软件开发程序缺点率（bug数量）。
2. 度量指标计算方法（1）度量指标评分标准依据软件开发程序缺点率（bug量）来确定，缺点率越高，其评价分就越低。
（2）缺点率起源关键是软件经过测试组测试后，所产生测试汇报；◆软件交付使用后十二个月内产生软件维护统计表;◆开发人员缺点率考评，关键依据测试汇报和软件维护统计；◆测试人员缺点率考评，依据软件维护统计。
（3）缺点率单位以程序单元为单位，相比较而得出缺点率值（原理：缺点数/单元总数）。
这里所指程序单元，是WBS分解后内容。
（4）开发人员缺点率计算方法● 依据测试汇报和软件维护统计中缺点类别，分别统计各类别缺点率，然后依据度量指标计分标准表来打分。
● 缺点数计算公式为：Total = ∑(Ci*Fi*Ki)； ● 缺点率计算公式为：V = Total / U ；其中i=1,2,...n 代表每个缺点；U 代表开发人员负责、已完成且已被测试程序单元总数；C 代表缺点所对应缺点等级权重系数；通常权重系数以"通常"缺点等级作为基数（权数设为1），"轻微"缺点等级可不用计算缺点率（权数设为0）。
软件度量指标集
软件度量指标集什么是软件度量指标集软件度量指标集是用于评估和衡量软件开发过程和软件产品质量的一组指标。
它们提供了一种定量的方法来评估软件开发的效果，并帮助开发团队识别和解决潜在的问题。
软件度量指标集可以帮助开发团队监控和改进软件开发过程，并提供有关软件质量和性能的关键信息。
软件度量指标集的分类软件度量指标集可以根据不同的维度进行分类。
下面是一些常见的分类方式：1. 功能度量指标功能度量指标用于评估软件的功能性能。
它们可以衡量软件是否满足用户需求，以及软件在不同环境下的性能表现。
一些常见的功能度量指标包括：•功能点（Function Point）：衡量软件的功能规模。
•代码覆盖率（Code Coverage）：衡量测试用例对代码的覆盖程度。
•故障密度（Fault Density）：衡量软件中的缺陷数量。
2. 质量度量指标质量度量指标用于评估软件的质量。
它们可以衡量软件的可靠性、可用性、可维护性等方面。
一些常见的质量度量指标包括：•故障率（Failure Rate）：衡量软件在一定时间内出现故障的频率。
•平均修复时间（Mean Time To Repair，MTTR）：衡量软件故障修复的平均时间。
•可用性（Availability）：衡量软件在给定时间内可用的概率。
3. 成本度量指标成本度量指标用于评估软件开发和维护的成本。
它们可以帮助开发团队控制开发成本，并为决策提供基础。
一些常见的成本度量指标包括：•人月（Person-Month）：衡量完成一项软件开发任务所需的工作量。
•开发成本（Development Cost）：衡量软件开发的总成本。
•维护成本（Maintenance Cost）：衡量软件维护的总成本。
软件度量指标的应用软件度量指标可以在软件开发的不同阶段和不同层面上应用。
下面是一些常见的应用场景：1. 项目管理软件度量指标可以帮助项目经理监控项目的进度和质量。
通过对比实际数据与预期目标，项目经理可以及时发现问题并采取措施进行调整。
软件质量度量指标及说明
软件质量度量指标及说明在软件开发过程中，了解和掌握软件质量度量指标是至关重要的，它们能够帮助我们评估软件的质量和可靠性。
下面将介绍一些常用的软件质量度量指标及其说明。
1. 可靠性：可靠性是指软件在规定条件下，按照规定的要求正常运行的能力。
常用的可靠性度量指标包括故障密度、平均失效间隔时间（MTTF）和平均修复时间（MTTR）等。
故障密度是指在特定时间内发生的故障数量与代码行数的比例，反映了软件中存在的错误密度。
2. 可用性：可用性是指软件按照规定的要求可供用户使用的程度。
常用的可用性度量指标包括平均时间到故障（MTTF）和平均修复时间（MTTR）。
MTTF是指在平均情况下，软件在无故障状态下运行的时间，越大表示可用性越高。
3. 可维护性：可维护性是指软件在修改、测试、故障排除和改进方面的容易程度。
常用的可维护性度量指标包括平均修复时间（MTTR）、修复效率和变更稳定性等。
MTTR是指修复故障所需的平均时间。
4. 可测试性：可测试性是指软件在测试过程中的容易程度。
常用的可测试性度量指标包括测试用例覆盖率和测试可行性。
测试用例覆盖率是指被测试的代码行数与被测试的总代码行数之比，反映了测试的覆盖程度。
5. 可移植性：可移植性是指软件在不同平台或环境下的适应性。
常用的可移植性度量指标包括代码冗余度和平台无关性。
代码冗余度是指在软件中存在的重复代码的比例。
以上是常用的软件质量度量指标及其说明，通过对这些指标的评估和分析，可以帮助开发团队提升软件的质量和可靠性。
在软件开发过程中，建议根据具体项目的需求和情况选择合适的度量指标，并结合实际情况进行评估和改进。
软件工程师的软件质量度量与分析
软件工程师的软件质量度量与分析软件工程师是在软件开发生命周期中负责设计、开发和测试软件系统的专业人士。
在软件工程师的角色中，确保软件质量是至关重要的。
为了评估和改进软件系统的质量，软件工程师需要掌握软件质量度量与分析的方法。
一、什么是软件质量度量与分析软件质量度量是通过度量指标对软件系统的特性进行量化评估的过程。
质量度量可以帮助软件工程师了解软件的稳定性、可靠性、可维护性等方面的特性是否满足预定的标准。
而软件质量分析是对质量度量结果进行解释、总结和分析的过程，以便帮助软件工程师制定改进软件系统的措施。
二、常见的软件质量度量指标1. 可靠性：软件系统在给定环境下正常工作的概率。
常用的可靠性度量指标包括故障率、平均修复时间等。
2. 可用性：软件系统为用户提供功能的时间比例。
可用性度量指标通常包括平均无故障时间、平均修复时间等。
3. 效率：软件系统在给定资源下完成任务所需的时间和资源消耗。
常用的效率度量指标包括响应时间、吞吐量等。
4. 可维护性：软件系统随时间演化的难易程度。
可维护性度量指标通常包括代码复杂度、缺陷密度等。
5. 安全性：软件系统抵御攻击和保护用户数据的能力。
安全性度量指标常包括漏洞数量、安全事件响应时间等。
三、软件质量度量的工具和技术1. 静态代码分析工具：通过分析源代码进行静态扫描，检测潜在的编码错误、不规范的编码风格等问题。
常用的静态代码分析工具包括SonarQube、PMD等。
2. 自动化测试工具：通过编写测试用例和执行自动化测试脚本，对软件系统进行功能、性能、安全等方面的测试。
常用的自动化测试工具包括Selenium、JUnit等。
3. 数据分析工具：通过分析软件系统生成的日志和运行数据，了解软件系统在不同使用场景下的性能、稳定性等方面的表现。
常用的数据分析工具包括ELK Stack、Grafana等。
四、软件质量度量与分析的好处1. 评估软件质量：软件质量度量与分析能够提供客观的数据，帮助软件工程师了解软件系统的各个方面的质量水平，为问题定位和改进提供依据。
2023年高级软考《信息系统项目管理师》考试全真模拟易错、难点汇编贰(答案参考)试卷号：11
2023年高级软考《信息系统项目管理师》考试全真模拟易错、难点汇编贰（答案参考）（图片大小可自由调整）一.全考点综合测验(共50题)1.【单选题】某软件开发项目的需求规格说明书第一次正式发布, 命名为《需求规格说明书V1.0》, 此后经过两次较小的升级, 版本号升至V1.2, 此时客户提出一次需求变更, 项目组接受了变更, 按客户的要求对需求规格说明书进行了较大的改动并通过评审, 此时版本号应升级为()A.V1.3B.V1.5C.V2.0D.V3.0正确答案：C2.【单选题】以下关于质量保证的叙述中，不正确的是：()。
A.实施质量保证是确保采用合理的质量标准和操作性定义的过程B.实施质量保证是通过执行产品检查并发现缺陷来实现的C.质量测量指标是质量保证的输入D.质量保证活动可由第三方团队进行监督，适当时提供服务支持正确答案：B3.【单选题】产品分析属于哪个过程的工具A.范围规划B.范围定义C.范围核实D.范围控制正确答案：B4.【单选题】软件设计过程是定义一个系统或组件( )的过程，其中描述软件的结构和组织，标识各种不同组件的设计是软件架构设计A.数据和控制流B.架构和接口C.对象模型D.数据模型正确答案：B5.【单选题】某软件的工作量是20000 行, 由4 人组成的开发小组开发, 每个程序员的生产效率是5000 行/ 人月, 每对程序员的沟通成本是250 行/ 人月, 则该软件需要开发() 月A.1B.1.04C.1.05D.1.08正确答案：D6.【单选题】软件过程管理一般包括: 启动和范围定义; 软件项目计划;(); 评审和评价; 关闭和软件工程度量A.需求管理B.软件项目实施C.项目测试D.变更管理正确答案：B7.【单选题】除了项目信息系统外，还有哪个工具出现在所有的整体管理过程中A.专家判断B.项目管理方法论C.事业环境因素D.组织过程资产正确答案：B8.【单选题】甲乙两人分别独立开发出相同主题的阀门，但甲完成在先，乙完成在后。
软件质量度量指标v1.0
软件质量度量指标v1.0软件质量指标度量V 1.02012.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.132.2 用例执行覆盖率【用例执行覆盖率】：计算测试用例执行总数除以与之一一对应的测试数之和，主要查看是否有测试用例执行遗漏或有效的情况。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件质量指标度量
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%
2.3缺陷修复率（截至于**年*月*日）
【缺陷修复率】计算已修复（关闭）的缺陷总数除以有效缺陷总数，主要查看是否有测试用例执行遗漏或有效的情况。
【公式】：∑修复（关闭）的缺陷数量（个） / ∑有效缺陷数量（个）【数据来源】：从公司部缺陷管理系统中导出数据：
【计算结果】：缺陷修复率=206/216*100%=95%
2.4缺陷遗留个数（截至于**年*月*日）
【缺陷遗留个数】统计待分配、待修改、重新处理的缺陷数量
【公式】：待分配+待修改+reopen状态的缺陷
【数据来源】：从公司部缺陷管理系统中导出数据
【计算结果】：缺陷遗留个数=10，且为C类以下bug(建议性缺陷)
2.5缺陷分布统计（模块缺陷率）
【模块缺陷率】：计算各模块的缺陷数除以总体缺陷之和，主要查看模块的质量的情况。
说明：此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒度是否划分均匀，模块的重要性，模块包含的容是否更容易发现bug等。
【公式】：本模块的缺陷数（个） / ∑各模块的缺陷数（个）*100%
【数据来源】：QC管理平台
【计算结果】可通过导出表格、分析图形的方式来度量结果
2.6缺陷分布统计（严重缺陷率）
【模块缺陷率】：计算各模块的严重缺陷数除以总体缺陷之和，主要查看模块的质量的情况。
说明：此指标不能单纯看结果，要结合实际情况进行分析，如模块的粒度是否划分均匀，模块的重要性，模块包含的容是否更容易发现bug等。
【公式】：本模块的严重缺陷数（个） / ∑各模块的严重缺陷数（个）*100% 【数据来源】：QC管理平台
【计算结果】可通过导出表格、分析图形的方式来度量结果
2.7缺陷密度及收敛
【模块缺陷率】：计算各版本缺陷数除以测试模块，主要查看版本是否趋于稳定情况，通过数据图表等方式来衡量版本交付的风险大小，是衡量版本是否可交付的重要依据之一。
说明：如果缺陷密度逐渐收敛，说明版本逐渐稳定；如果趋势起伏不定，需
要分析研究原因，查找不稳定的原因；如果缺陷密度趋势呈波状，一定要重视起来，说明版本及其不稳定，确认发布时要慎重。
【公式】：本版本的缺陷数（个） / ∑已测各模块数（个）
【数据来源】：日常跟踪数据、QC管理平台
【计算结果】可通过导出表格、分析图形的方式来度量结果
趋于收敛的缺陷密度图：
起伏不定的缺陷密度图：
3测试过程质量指标
3.1缺陷探测率
【缺陷探测率】：计算部发现的缺陷数除以部发现的缺陷数与用户发现的缺陷数之和，主要查看部发现缺陷的能力。
说明：缺陷探测率越高，即部发现的bug数越多，发布后客户发现的bug 数就越少，质量成本就越低。
【公式】：部发现的缺陷数（个） / （部发现的缺陷数（个）+用户发现的缺陷数（个））*100%
【数据来源】：日常跟踪表，QC平台，用户缺陷平台或列表
【计算结果】：缺陷探测率=80/(80+5)=94%
3.2有效缺陷率
【有效缺陷率】：计算被开发人员确认的BUG数总和除于本人上报BUG的总和，可用于查看测试人员的个人测试质量，也可用于查看整个测试组的测试质量。
无效BUG状态包括：问题重复、不是问题、不可复现状态。
这项指标用于考察测试人员发现的、被确认为缺陷的缺陷数高低或者百分比，数和比率越高测试质量越高。
注意：由于系统框架根本性的、初始化参数设置错误引发的、错误数据、错误环境等而开发人员因无法修正、可以通过改变环境而无需修改程序、重新导入数据、再次发布而解决的BUG为有效BUG
【公式】：测试人员发现的有效缺陷数（个） /测试人员发现的总缺陷数（个）*100%
【数据来源】：日常跟踪表，QC平台，用户缺陷平台
【计算结果】
3.1用例执行效率
【用例执行效率】：计算测试人员执行的用例数除以执行测试的时间，主要查看测试人员执行测试的效率。
说明：此指标的统计需要有一定的前提条件：用例的执行步骤相对来说分布较均匀，执行时间在一个较长的时间段
【公式】：∑测试人员执行的用例数（个） / ∑执行用例的时间（小时）【数据来源】：日常跟踪表，QC平台，用户缺陷平台或列表
【计算结果】：
3.2缺陷发现率
【缺陷发现率】：计算测试人员各自发现的缺陷数总和除于各自所花费的
测试时间总和。
由于执行效率不能足够代表测试人员是否认真工作，那么，每小时发现的缺陷数就是重要的考核指标，测试的工作可以通过这项指标得到反馈。
注意：此项指标的统计可作为测试质量的一个依据，但实际工作中如果用此指标作为考核测试人员的唯一依据会带来很多问题，比如，缺陷数可通过减小缺陷粒度、增加微小缺陷、增加不能确定bug数来提高分子数，这样会增加缺陷流转处理成本，会带来更多的问题。
建议慎用。
【公式】：∑提交缺陷数（个） / ∑执行测试的有效时间（小时）
【数据来源】：日常跟踪表，QC平台，用户缺陷平台或列表
【计算结果】：
4交付质量指标
4.1加载回退率
【加载回退率】：计算计划上线需求个数减去加载回退的需求个数之差除以计划上线需求个数，主要查看新需求上线交付质量。
说明：上线加载当日无法满足上线条件，导致回退。
【公式】：（上线需求数（个）-加载当时回退需求数（个））/上线需求数（个）*100%
【数据来源】：生产门户需求管控平台，客户需求管理平台等
【计算结果】加载回退率=（15-1）/15*100%=93%
4.2故障回退率
【加载回退率】：计算计划上线需求个数减去故障回退的需求个数之差除以计划上线需求个数，主要查看新需求上线交付质量。
说明：上线加载次日，用户无法使用，引发投诉，进行故障回退。
【公式】：（上线需求数（个）-故障回退需求数（个））/上线需求数（个）*100%
【数据来源】：生产门户需求管控平台，客户需求管理平台/缺陷管理平台等
【计算结果】故障回退率=（16-2）/16*100%=88%
5版本说明
1.鉴于自己的经验有限，尤其侧重于测试方面，故总结的度量指标多为测试指
标。
2.其实软件的质量保证需要多种途径、多个层次、多个阶段有计划有步骤地去
实现，测试只是其中一条途径。
休哈特说“产品质量不是检验出来的，而是生产出来的”，可见“测试只能发现问题，并不能解决问题”。
戴明博士说“引起效率低下和不良质量的原因主要在公司的管理系统而不在员工”，但是我们不能因此而放弃对高质量的追求。
3.我正在系统学习质量控制、质量保证、质量改进方面的知识，后续会整理出
更为全面的度量指标，和同行及致力于提高软件质量的朋友们分享。