常见软件项目度量指标介绍
软件工程师中的常见软件工程软件度量与质量评估题解析
软件工程师中的常见软件工程软件度量与质量评估题解析软件工程师是现代信息技术领域中的重要职业之一。
对于软件工程师来说，掌握软件度量与质量评估是非常关键的。
本文将对软件工程中常见的软件度量与质量评估题进行解析，帮助读者更好地理解和应用这些知识。
一、软件度量软件度量是指根据一定的度量方法和指标对软件进行度量和评估的过程。
常见的软件度量指标包括代码行数、代码覆盖率、复杂度指标等。
1. 代码行数代码行数是用来度量软件规模的一种常见指标。
在软件开发过程中，开发人员可以根据需求和功能模块的复杂性来确定项目的代码行数。
通过对代码行数的度量，可以对软件规模进行评估，并为项目的进度和资源分配提供依据。
2. 代码覆盖率代码覆盖率是用来衡量测试用例是否覆盖了代码中的各个分支和路径的指标。
通过对代码覆盖率的度量，可以评估测试的完整性和有效性，从而提高软件的质量和可靠性。
3. 复杂度指标复杂度指标可以度量软件代码的复杂程度。
常见的复杂度指标包括圈复杂度、耦合度和内聚度等。
通过对复杂度指标的度量和分析，可以帮助开发人员评估和改进代码的质量和可维护性。
二、软件质量评估软件质量评估是根据一定的评估方法和标准，对软件进行质量评估和改进的过程。
常见的软件质量评估方法包括静态分析、动态测试和用户反馈等。
1. 静态分析静态分析是通过对软件源代码进行检查和分析，来评估软件质量的方法。
常见的静态分析技术包括代码审查、抽象语法树分析和代码规范检查等。
通过静态分析，可以发现代码中的潜在问题和不良实践，从而提高软件的可读性和可维护性。
2. 动态测试动态测试是通过执行软件系统的功能和性能测试用例，来评估软件质量的方法。
常见的动态测试技术包括单元测试、集成测试和系统测试等。
通过动态测试，可以验证软件的功能正确性和性能稳定性，发现和修复潜在的缺陷。
3. 用户反馈用户反馈是根据用户对软件的实际使用情况和反馈意见，来评估软件质量的方法。
通过用户反馈，可以了解用户对软件的满意度和改进建议，从而不断改进和优化软件的功能和用户体验。
常见软件项目度量指标 和控制指标
软件项目度量指标和控制指标是软件开发过程中非常重要的一部分，它们能够帮助开发团队和管理人员评估项目进展情况，及时发现并解决问题，确保项目按时交付、质量可控。
本文将从常见软件项目度量指标和控制指标两个方面进行探讨，为软件项目管理提供有益的参考。
一、常见软件项目度量指标对于软件项目管理来说，度量指标是评估项目进展和质量的重要依据，合理选择和使用度量指标能够帮助团队领导及时发现问题、及时调整问题和保证项目交付质量，常见的软件项目度量指标有：1. 代码行数：代表了软件代码的规模，是度量软件规模的最基本指标之一。
代码行数在软件开发过程中被广泛使用，可以用于评估软件规模、成本估算、进度控制等方面。
2. 功能点数：是根据软件功能区分的度量指标，它能够更好地反映软件的实际使用价值。
功能点数是一个重要的度量指标，可以帮助团队直观地了解软件的功能复杂度和开发进度。
3. 缺陷密度：是度量软件质量的重要指标之一，它可以帮助团队了解软件的缺陷情况，以及缺陷的严重程度。
通过缺陷密度指标，团队可以及时发现和解决软件质量问题，提高软件质量。
4. 代码覆盖率：是度量软件测试覆盖情况的指标，通过代码覆盖率可以了解软件的测试覆盖情况，帮助团队评估测试质量和发现测试遗漏情况。
5. 进度指标：包括工作完成进度、任务完成比例、工作量增减变化情况等，可以帮助团队领导及时了解项目进展情况，调整项目计划和资源分配。
二、常见软件项目控制指标除了度量指标，软件项目的控制指标也是非常重要的，它们能够帮助团队领导控制项目进度、成本和质量，确保项目按时交付和质量可控。
常见的软件项目控制指标有：1. 成本偏差（Cost Variance，CV）：是衡量项目成本偏离预算的指标，CV=实际成本-计划成本，通过成本偏差指标可以帮助团队领导了解项目成本控制情况，及时调整成本预算和资源分配。
2. 进度偏差（Schedule Variance，SV）：是衡量项目进度偏离计划的指标，SV=实际完成工作-计划完成工作，通过进度偏差指标可以帮助团队领导了解项目进度控制情况，及时调整项目计划和资源分配。
软件测试中的质量度量和指标
软件测试中的质量度量和指标软件测试是保证软件质量的重要环节，而质量度量和指标则是评估测试过程和结果的重要依据。
本文将探讨软件测试中常用的质量度量和指标，帮助读者更好地理解和应用于实际项目中。
一、测试覆盖率测试覆盖率是衡量测试过程中代码执行情况的指标。
它能够告诉我们测试用例是否覆盖了所要求的功能和代码。
常用的测试覆盖率指标有语句覆盖率、分支覆盖率和路径覆盖率等。
语句覆盖率是指测试用例执行时是否覆盖了代码中的每一条语句。
它可以帮助我们确定是否有未执行的代码块，从而发现潜在的缺陷。
分支覆盖率是指测试用例执行时是否覆盖了代码中的每一条分支语句。
它能够帮助我们发现条件判断的问题，确保程序在不同分支上的表现正常。
路径覆盖率是指测试用例执行时是否覆盖了代码中的所有可能路径。
它是最全面的覆盖率指标，可以帮助我们评估测试用例的全面性和有效性。
二、缺陷密度缺陷密度是指在软件测试过程中发现的缺陷数量与代码行数之比。
它能够告诉我们单位代码行数中存在的缺陷数量，从而评估代码的质量。
缺陷密度的计算公式为：缺陷密度 = 缺陷数量 / 代码行数通常情况下，缺陷密度应该尽可能地低，因为较低的缺陷密度意味着代码质量较高。
如果缺陷密度超过了预期的阈值，就需要进一步分析和改进测试过程。
三、缺陷修复效率缺陷修复效率是指在软件测试过程中发现的缺陷修复的速度和效果。
它可以帮助我们评估开发团队的响应能力和解决问题的能力。
缺陷修复效率可以通过以下指标进行评估：1. 平均修复时间（MTTR）：指从发现缺陷到修复缺陷所需要的平均时间。
2. 平均修复周期（MTBF）：指缺陷修复之间的平均时间间隔。
3. 缺陷关闭率：指在一定时间内，成功修复并关闭的缺陷所占的比率。
通过对缺陷修复效率的评估，可以及时发现并解决问题，提高软件质量和用户满意度。
四、测试效率测试效率是指在规定时间内完成测试任务所需要的工作量和时间。
它可以帮助我们评估测试团队的运作效率和资源利用率。
软件项目质量测量指标
软件项目质量测量指标
软件项目质量测量指标是用来评估和衡量软件项目质量的指标或标准。
以下是一些常用的软件项目质量测量指标：1. 可靠性：衡量软件系统在固定时间内无故障运行的能力，通常用故障率、平均故障间隔时间等指标进行衡量。
2. 可用性：评估软件系统对用户的可用性和易用性，通常通过用户满意度、系统可用性时间等指标进行评估。
3. 性能：评估软件系统在某个负载条件下的运行效率和资源利用率，通常使用响应时间、吞吐量等指标来衡量。
4. 可维护性：评估软件系统的可维护性和可扩展性，通常使用代码复杂度、代码可读性、软件体系结构的模块化程度等指标来衡量。
5. 安全性：评估软件系统的安全性和防护能力，通常使用漏洞数量、攻击成功率等指标进行评估。
6. 可测试性：评估软件系统的可测试性和测试覆盖率，通常使用代码覆盖率、测试用例执行率等指标进行评估。
7. 可移植性：评估软件系统在不同平台、环境下的可移植性，通常使用代码健壮性、编程语言独立性等指标进行评估。
这些指标可以根据软件项目的特定需求和目标进行定制和衡量，以评估和改进软件项目的质量。
华为公司 常见软件度量指标
常见软件项目度量指标介绍发布时间:未知来源:网络转载字体:小中大|上一篇下一篇|打印|我要投稿|推荐标签：软件测试基本度量项持续时间偏差(%)进度偏差(%)工作量偏差(%)规模偏差(%)分配需求稳定性指数(%)软件需求稳定性指数(%)((实际持续时间-计划持续时间)/计划持续时间)*100 (持续时间不包含非工作日)((实际结束时间-计划结束时间)/计划持续时间)*100(实际工作量-计划工作量)/计划工作量((实际规模-计划规划)/计划规模)*100(1-(修改、增加或删除的分配需求数/初始的分配需求数))*100(1-(修改、增加或删除的软件需求数/初始的软件需求数))*100((发布后缺陷发现总数-(发布后前测试计划本身缺陷数)/规发布前缺陷发现密度(个/KLOC)遗留缺陷密度(个/KLOC)(遗留缺陷：测试部发现的缺陷)生产率(LOC/人天)SRS评审缺陷发现密度(个/页)STP评审缺陷发现密度(个/用例)HLD评审缺陷发现密度(个/页)ITP评审缺陷发现密度(个/用例)LLD评审缺陷发现密度(个/页)UTP评审缺陷发现密度(个/用例)CODE评审缺陷发现密度(个/KLOC)UT缺陷发现密度(个/KLOC)IT缺陷发现密度(个/KLOC)ST缺陷发现密度(个/KLOC)模(KLOC)(这里的发布指开发向测试部发布)(测试部发现缺陷数-测试部测试计划本身缺陷数)/规模(KLOC) 软件规模(LOC)/总工作(人天)SRS评审发现的缺陷数/SRS文档页数STP评审发现的缺陷数/ST用例数HLD评审发现的缺陷数/HLD文档页数ITP评审发现的缺陷数/IT用例数LLD评审发现的缺陷数/LLD文档页数UTP计划评审发现的缺陷数/UT用例数CODE评审发现缺陷数/编码阶段代码规模UT发现缺陷数/UT阶段代码规模IT发现缺陷数/IT阶段代码规模ST发现缺陷数/ST阶段代码规模考)SR缺陷引入密度(个/页)HLD缺陷引入密度(个/页)SRS类型缺陷数/SRS文档页数HLD类型缺陷数/HLD文档页数质量控制活动缺陷发现密度(度量目的：建立基线，评估评审、测试是否充分提供参考)缺陷类型引入密度：(度量目的：建立基线，为分析能力水平薄弱环节及交付件质量提供参LLD缺陷引入密度(个/页)Code缺陷引入密度(个/KLOC)SRS评审有效性(%)HLD评审有效性(%)LLD评审有效性(%)代码评审有效性(%)LLD类型缺陷数/LLD文档页数CODE类缺陷数/代码规模SRS评审发现的SRS类缺陷数/SRS类缺陷总数HLD评审发现的HLD类缺陷数/HLD类缺陷总数LLD评审发现的LLD类缺陷数/LLD类缺陷总数代码评审发现的Code类缺陷数/Code类缺陷总数是否合理角度提供参考)评审活动的有效性(度量目的：建立基线，对相关评审是否充分提供参考)每千行代码的文档规模(度量目的：建立基线，为评估交付件的质量从设计是否充分、粒度每千行代码SRS文档规模(pages/KLOC)每千行代码HLD文档规模(pages/KLOC)每千行代码LLD文档规模(pages/KLOC)SRS文档页数/代码规模HLD文档页数/代码规模LLD文档页数/代码规模质量成本(评审工作量+返工工作量+缺陷修改工作量+测试计划准备工作量+测试执行工作量＋培训工作量＋质量保证工作量)/实际总工作量(返工工作量+缺陷修改工作量)/实际总工作量交付件生产率SRS文档页数/(SRS文档准备工作量+SRS评审工作量+SRS修改工作量)ST用例数/(STP准备工作量+STP评审工作量+STP修改工作量)HLD文档页数/(HLD文档准备工作量+HLD评审工作量+HLD修改工作量)ITP用例数/(ITP准备工作量+ITP评审工作量+ITP修改工作量)UTP用例数/(UTP准备工作量+UTP评审工作量+UTP修改工作量)修改工作量)测试执行效率UT用例数/(UT准备工作量+UT用例执行工作量+UT缺陷修改工作量)IT用例数/(IT准备工作量+IT用例执行工作量+IT缺陷修改工作量)ST用例数/(ST准备工作量+ST用例执行工作量+ST缺陷修改工作量)度角度提供一个参考)质量成本(%)返工成本指数(%)SRS文档生产率(页/人天)STP用例生产率(用例/人天)HLD用例生产率(页/人天)ITP用例生产率(页/人天)UTP用例生产率(页/人天)编码阶段代码生产率(LOC/人编码阶段实际代码规模/(编码工作量+代码评审工作量+代码天)UT用例执行效率(用例/人天)IT用例执行效率(用例/人天)ST用例执行效率(用例/人天)每千行代码测试用例规模(度量目的：建立基线，为评估交付件的质量从设计是否充分、粒每千行代码ST用例规模(用例/KLOC)每千行代码IT用例规模(用例/KLOC)每千行代码UT用例规模(用例/KLOC)UT实测规模缺陷发现密度(个/KLOC)IT实测规模缺陷发现密度(个/KLOC)ST实测规模缺陷发现密度(个/KLOC)总结:ST用例数/代码规模IT用例数/代码规模UT用例数/代码规模实测规模缺陷发现密度(度量目的：建立基线，为评估测试用例的质量提供一个参考)UT发现的缺陷数/UT活动实际测试代码规模IT发现的缺陷数/UT活动实际测试代码规模ST发现的缺陷数/UT活动实际测试代码规模开展度量活动的一个最关键的因素是要保证度量基础数据的有效、准确性,否则度量结果将是垃圾,反而会起误导作用.搜集准确有效的度量数据工作量并不小，所以决定采用哪些度量项需要从投入和产出来衡量。
软件质量度量指标及说明
软件质量度量指标及说明在软件开发过程中，了解和掌握软件质量度量指标是至关重要的，它们能够帮助我们评估软件的质量和可靠性。
下面将介绍一些常用的软件质量度量指标及其说明。
1. 可靠性：可靠性是指软件在规定条件下，按照规定的要求正常运行的能力。
常用的可靠性度量指标包括故障密度、平均失效间隔时间（MTTF）和平均修复时间（MTTR）等。
故障密度是指在特定时间内发生的故障数量与代码行数的比例，反映了软件中存在的错误密度。
2. 可用性：可用性是指软件按照规定的要求可供用户使用的程度。
常用的可用性度量指标包括平均时间到故障（MTTF）和平均修复时间（MTTR）。
MTTF是指在平均情况下，软件在无故障状态下运行的时间，越大表示可用性越高。
3. 可维护性：可维护性是指软件在修改、测试、故障排除和改进方面的容易程度。
常用的可维护性度量指标包括平均修复时间（MTTR）、修复效率和变更稳定性等。
MTTR是指修复故障所需的平均时间。
4. 可测试性：可测试性是指软件在测试过程中的容易程度。
常用的可测试性度量指标包括测试用例覆盖率和测试可行性。
测试用例覆盖率是指被测试的代码行数与被测试的总代码行数之比，反映了测试的覆盖程度。
5. 可移植性：可移植性是指软件在不同平台或环境下的适应性。
常用的可移植性度量指标包括代码冗余度和平台无关性。
代码冗余度是指在软件中存在的重复代码的比例。
以上是常用的软件质量度量指标及其说明，通过对这些指标的评估和分析，可以帮助开发团队提升软件的质量和可靠性。
在软件开发过程中，建议根据具体项目的需求和情况选择合适的度量指标，并结合实际情况进行评估和改进。
软件工程中的软件度量和度量指标
软件工程中的软件度量和度量指标在软件工程中，软件度量和度量指标是评估软件质量和效率的重要手段。
软件度量是指用数量化的方法对软件开发过程中的相关对象进行量化和评估，以便更好地理解和控制软件开发过程中的进展和质量。
而度量指标是衡量软件度量的标准和指示，旨在提高软件开发、测试、维护和实施等环节的效率和质量。
软件度量的目的在于帮助软件开发人员更好地理解、掌握和控制软件开发过程，以更好地满足用户的需求。
常见的软件度量包括代码行数、功能点、代码质量、缺陷数、代码复杂度等。
其中，代码行数和功能点是衡量软件规模的重要指标。
代码质量主要包括可读性、可维护性、可靠性、安全性和性能等方面。
缺陷数和代码复杂度则主要用来衡量软件的质量和可维护程度。
度量指标则是用来衡量软件度量的标准和指示。
不同的度量指标具有不同的意义和影响。
衡量软件大小的度量指标包括代码行数、功能点、工作量等。
衡量软件质量的度量指标包括代码复杂度、可读性、可维护性、缺陷密度等。
而衡量软件开发过程和效率的度量指标则包括需求变更率、代码重用率、开发进度等。
在实际应用中，软件度量和度量指标应该根据项目特点和需求进行具体的选择和应用。
例如，对于小型项目，代码行数和功能点可能是最为实用的度量指标，而对于大型复杂项目，则需要更多的度量指标来全面评估和控制软件开发过程。
此外，在选择度量指标时还需要注意指标的可靠性和有效性，以确保度量结果的准确性和可信度。
对于软件开发人员来说，掌握软件度量和度量指标是提高软件质量和效率的关键。
通过对软件开发过程中各个环节的度量和评估，可以及时发现和解决问题，避免项目延误和质量问题。
因此，软件度量和度量指标不仅是衡量软件质量的重要指标，还是软件开发管理和控制的重要手段。
常见的软件过程中的度量指标
常见的软件过程中的度量指标英文回答：Common Software Process Metrics.Software process metrics are quantitative measures of the characteristics of a software process. They are used to track progress, identify bottlenecks, and improve the quality of the process. Common software process metrics include:Time metrics: These metrics measure the amount of time it takes to complete a software process or activity. Examples of time metrics include:Cycle time: The time it takes from the start of a software process to the delivery of the final product.Lead time: The time it takes from the initial request for a software product to the delivery of the finalproduct.Defect detection time: The time it takes from the introduction of a defect into a software product to its detection.Cost metrics: These metrics measure the amount of money it costs to complete a software process or activity. Examples of cost metrics include:Total cost of ownership: The total cost of a software product over its entire lifetime, including development, maintenance, and support costs.Return on investment: The ratio of the benefits of a software product to the costs of developing and maintaining it.Quality metrics: These metrics measure the quality of a software product or process. Examples of quality metrics include:Defect density: The number of defects in a software product per unit of code.Mean time between failures: The average amount of time between failures of a software system.Customer satisfaction: The level of satisfaction of customers with a software product or process.Productivity metrics: These metrics measure the productivity of a software team or individual. Examples of productivity metrics include:Lines of code per day: The number of lines of code written by a developer per day.Story points completed per sprint: The number of story points completed by a team in a sprint.Process maturity metrics: These metrics measure the maturity of a software process. Examples of process maturity metrics include:Capability maturity model integration (CMMI) level: A measure of the maturity of a software process based onthe Capability Maturity Model Integration framework.ISO/IEC 27001 certification: A certification thata software process meets the requirements of the ISO/IEC 27001 information security standard.Software process metrics can be used to improve the quality and efficiency of software processes. By tracking these metrics, organizations can identify areas for improvement and make changes to their processes accordingly.中文回答：常见的软件过程度量指标。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
判断系统测试的充分性
11
3
测试发现各类型的缺陷
缺陷个数
个
编码阶段
直接统计
80-20分析：对缺陷类型按缺陷个数排序，找出最多的20%的缺陷类型
根据类型的分布，查找错误的原因，定义编码或设计的改进措施
系统测试阶段
12
3
单元测试
缺陷密度
个/KLOC
编码阶段
单元测试发现的缺陷个数/代码规模
和项目目标对比
UTP用例生产率(页/人天)
UTP用例数/(UTP准备工作量+UTP评审工作量+UTP修改工作量)
编码阶段代码生产率(LOC/人天)
编码阶段实际代码规模/(编码工作量+代码评审工作量+代码修改工作量)
测试执行效率
UT用例执行效率(用例/人天)
UT用例数/(UT准备工作量+UT用例执行工作量+UT缺陷修改工作量)
每千行代码ST用例规模(用例/KLOC)
ST用例数/代码规模
每千行代码IT用例规模(用例/KLOC)
IT用例数/代码规模
每千行代码UT用例规模(用例/KLOC)
UT用例数/代码规模
实测规模缺陷发现密度(度量目的：建立基线，为评估测试用例的质量提供一个参考)
UT实测规模缺陷发现密度(个/KLOC)
UT发现的缺陷数/UT活动实际测试代码规模
缺陷类型引入密度：(度量目的：建立基线，为分析能力水平薄弱环节及交付件质量提供参考)
SR缺陷引入密度(个/页)
SRS类型缺陷数/SRS文档页数
HLD缺陷引入密度(个/页)
HLD类型缺陷数/HLD文档页数
LLD缺陷引入密度(个/页)
LLD类型缺陷数/LLD文档页数
Code缺陷引入密度(个/KLOC)
CODE类缺陷数/代码规模
15
3
系统测试
测试用例的有效性
%
系统测试阶段
依据测试用例发现的缺陷个数/所有的缺陷个数
和项目目标对比
评价测试用例的有效性，判断是否需要提高测试用例的设计技术
IT用例执行效率(用例/人天)
IT用例数/(IT准备工作量+IT用例执行工作量+IT缺陷修改工作量)
ST用例执行效率(用例/人天)
ST用例数/(ST准备工作量+ST用例执行工作量+ST缺陷修改工作量)
每千行代码测试用例规模(度量目的：建立基线，为评估交付件的质量从设计是否充分、粒度角度提供一个参考)
建立单元测试的性能基线，用以制定项目的质量目标
13
3
单元测试
单元测试用例相对物理规模的密度
个/KLOC
编码阶段
单元测试用例个数（或断言的个数）/KLOC
和项目目标对比
判断单元测试的充分性
14
3
集成测试
集成测试用例相对物理规模的密度
个/KLOC
集成阶段
集成测试用例个数/KLOC
和项目目标对比
判断集成测试的充分性
分配需求稳定性指数(%)
(1-(修改、增加或删除的分配需求数/初始的分配需求数))*100
软件需求稳定性指数(%)
(1-(修改、增加或删除的软件需求数/初始的软件需求数))*100
发布前缺陷发现密度(个/KLOC)
((发布后缺陷发现总数-(发布后前测试计划本身缺陷数)/规模(KLOC)(这里的发布指开发向测试部发布)
STP用例生产率(用例/人天)
ST用例数/(STP准备工作量+STP评审工作量+STP修改工作量)
HLD用例生产率(页/人天)
HLD文档页数/(HLD文档准备工作量+HLD评审工作量+HLD修改工作量)
ITP用例生产率(页/人天)
ITP用例数/(ITP准备工作量+ITP评审工作量+ITP修改工作量)
维护阶段
2
1
软件模块
缺陷密度
个/KLOC
系统测试阶段
缺陷个数/代码规模
80-20分析：对所有模块的缺陷密度进行排序比较，找出缺陷密度最大的20%模块
找出质量最差的模块，采取改进措施
3
1
遗留的缺陷
缺陷个数
个
系统测试阶段
上阶段遗留的缺陷个数+本阶段发现的缺陷个数-本阶段解决的缺陷个数
和阶段出口准则对比
里程碑评审决策的依据
每千行代码的文档规模(度量目的：建立基线，为评估交付件的质量从设计是否充分、粒度是否合理角度提供参考)
每千行代码SRS文档规模(pages/KLOC)
SRS文Байду номын сангаас页数/代码规模
每千行代码HLD文档规模(pages/KLOC)
HLD文档页数/代码规模
每千行代码LLD文档规模(pages/KLOC)
LLD文档页数/代码规模
和项目目标对比
建立测试活动的投入产出模型，用以估计为了达到项目的质量目标而需要的测试工作量
9
2
系统测试
系统测试用例相对逻辑规模的密度
个/功能点
系统测试阶段
系统测试用例个数/需求的规模
和项目目标对比
判断系统测试的充分性
10
2
系统测试
系统测试用例相对物理规模的密度
个/KLOC
系统测试阶段
系统测试用例个数/代码规模
IT实测规模缺陷发现密度(个/KLOC)
IT发现的缺陷数/UT活动实际测试代码规模
ST实测规模缺陷发现密度(个/KLOC)
ST发现的缺陷数/UT活动实际测试代码规模
总结:
开展度量活动的一个最关键的因素是要保证度量基础数据的有效、准确性,否则度量结果将是垃圾,反而会起误导作用.搜集准确有效的度量数据工作量并不小，所以决定采用哪些度量项需要从投入和产出来衡量。
质量成本
质量成本(%)
(评审工作量+返工工作量+缺陷修改工作量+测试计划准备工作量+测试执行工作量＋培训工作量＋质量保证工作量)/实际总工作量
返工成本指数(%)
(返工工作量+缺陷修改工作量)/实际总工作量
交付件生产率
SRS文档生产率(页/人天)
SRS文档页数/(SRS文档准备工作量+SRS评审工作量+SRS修改工作量)
个/小时
编码阶段
代码走查发现的缺陷个数/代码走查的工作量
和项目目标对比
比较评审与测试的效率，以确定二者投入工作量的比例
7
2
单元测试
测试效率
个/小时
编码阶段
单元测试发现的缺陷个数/单元测试的工作量
和项目目标对比
建立单元测试的性能基线，预测单元测试投入的工作量
8
2
系统测试
测试效率
个/小时
系统测试阶段
缺陷个数/测试工作量
测试过程中的常用度量元
序号
优先级
度量对象
度量元
度量单位
采集周期
采集/计算方法
分析方法
作用
1
1
用户发现的各类型的缺陷
缺陷个数
个
交付阶段
直接统计
80-20分析：对缺陷类型按缺陷个数排序，找出客户发现的最多的20%的缺陷类型
分析客户的关注点是什么？为什么客户能发现这些类型的缺陷，为什么我们没有测试出来？定义改进措施
常见软件项目度量指标介绍
基本度量项
持续时间偏差(%)
((实际持续时间-计划持续时间)/计划持续时间)*100 (持续时间不包含非工作日)
进度偏差(%)
((实际结束时间-计划结束时间)/计划持续时间)*100
工作量偏差(%)
(实际工作量-计划工作量)/计划工作量
规模偏差(%)
((实际规模-计划规划)/计划规模)*100
STP评审缺陷发现密度(个/用例)
STP评审发现的缺陷数/ST用例数
HLD评审缺陷发现密度(个/页)
HLD评审发现的缺陷数/HLD文档页数
ITP评审缺陷发现密度(个/用例)
ITP评审发现的缺陷数/IT用例数
LLD评审缺陷发现密度(个/页)
LLD评审发现的缺陷数/LLD文档页数
UTP评审缺陷发现密度(个/用例)
4
1
各级别严重程度的缺陷
缺陷个数
个
系统测试阶段
直接统计
和项目目标对比
判断是否达到测试结束与产品发布准则
5
1
回归测试活动
缺陷个数
个
系统测试阶段
直接统计
趋势线分析：横坐标为某次回归测试，纵坐标为缺陷个数，建立拟合曲线，判断收敛性
针对每次回归测试活动，进行收敛分析，作为发布决策的依据
6
2
代码走查
代码走查的效率
评审活动的有效性(度量目的：建立基线，对相关评审是否充分提供参考)
SRS评审有效性(%)
SRS评审发现的SRS类缺陷数/SRS类缺陷总数
HLD评审有效性(%)
HLD评审发现的HLD类缺陷数/HLD类缺陷总数
LLD评审有效性(%)
LLD评审发现的LLD类缺陷数/LLD类缺陷总数
代码评审有效性(%)
代码评审发现的Code类缺陷数/Code类缺陷总数
遗留缺陷密度(个/KLOC)(遗留缺陷：测试部发现的缺陷)
(测试部发现缺陷数-测试部测试计划本身缺陷数)/规模(KLOC)
生产率(LOC/人天)
软件规模(LOC)/总工作(人天)
质量控制活动缺陷发现密度(度量目的：建立基线，评估评审、测试是否充分提供参考)
SRS评审缺陷发现密度(个/页)
SRS评审发现的缺陷数/SRS文档页数
UTP计划评审发现的缺陷数/UT用例数