| 度量的概念
根据一定的规则，将数字或符号赋与系统、构件、过程等实体的特定属性，从而使我们能清晰地理解该实体及其属性。
简而言之，度量就是对事物属性的量化表示。
度量的目的
度量的根本目的是通过量化的分析和综合，帮助我们提高生产率，提高产品质量，降低研发成本、维护成本和产品研发周期，提高用户满意度，为组织持续改进提供量化的指标和反馈。
度量本身不是目的，而是手段。
度量的过程定义
测试的度量
多纬度的测试度量一
测试广度的度量指所有需求中有多少需求在某一时刻已测试，从而度量测试计划执行、测试进度等状态。
事儿一：
基于功能和性能测试覆盖评测是对被测试的功能和非功能点的覆盖率分析，是根据测试已经执行的功能点的多少来表示的。这种测试覆盖策略类型广泛的用于各个行业，产品的测试度量中。
其中非功能点包括性能，压力，易用性，环保，兼容性……
事儿二：
基于代码的测试覆盖评测是对被测试的程序代码语句、路径或条件的覆盖率分析，是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。
代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效。
多纬度的测试度量二
测试深度的度量是指被测试覆盖的独立基本路径占程序中基本路径的总数的比值。基本路径数目的度量可以用McCabe环形计算复杂度方法来计算。
事儿一：
测试用例的深度、质量和有效性。
测试用例的深度（Test Case Depth）度量可以表示为每KLOC的测试用例数或每个功能点/对象点的测试用例数。
测试用例的质量（Test Case Quality）可以用由测试用例发现的缺陷数量来度量，
即TCQ = 测试用例发现的缺陷数量/总的缺陷数量
测试用例的效率可以用每100或1000个测试用例所发现的缺陷数来衡量。
多纬度的测试度量三
测试用例的度量，除了前面提到的覆盖率和深度。还有重要的度量参数是测试用例的执行率，通过率和测试用例的执行质量和效率。
事儿一：
测试执行的质量一般可以用于不同测试阶段给下一测试阶段所遗留的软件缺陷和总缺陷数的比值来衡量，一般要求低于0.5%。
测试执行效率可以用下列几种方法来综合度量：
每个人日所执行的测试用例数
每个人日所发现的缺陷数
每修改KLOC所运行的测试用例
事儿二：
测试用例的执行率是指所有测试用例已经执行的用例和总用例的比
测试用例的通过率是指所有执行并通过的用例和总用例的比。
这两个参数不但能反应最总的测试质量而且通过过程的数据记录可以反应测试过程中的测试进度和测试效率等。
多纬度的测试度量四
相关缺陷的度量
BUG数量
BUG级别统计
BUG分布统计（模块）
BUG分布统计（阶段）
BUG密度
BUG关闭率
BUG状态统计
事儿一：
事儿二：
事儿三：
多纬度的测试度量五
其它相关度量：测试规模度量，人员效率素质度量，项目偏移量度量，工作偏移量度量，测试用例密度度量，返工成本度量……
实事儿
世界500强工业控制类公司，研发生产流程中对测试的度量。测试管理工具为Quality
Center，Bug管理工具为Clear Quest。
测试覆盖率
测试覆盖率是指测试用例对需求的覆盖情况。
计算公式：已设计测试用例的需求数/需求总数。测试覆盖率从纬度上说包括广度覆盖和深度覆盖；从内容上说包括用户场景覆盖、功能覆盖、功能组合覆盖、系统场景覆盖。
测试执行通过率
测试执行通过率，指在实际执行的测试用例中，执行结果为“通过”的测试用例比率。
计算公式：执行结果为“通过”的测试用例数/实际执行的测试用例总数。
测试执行率
执行率，顾名思义，就是指实际执行过程中确定已经执行的测试用例比率。
计算公式：已执行的测试用例数/设计的总测试用例数。
未解决缺陷状态
缺陷未解决状态，指某个阶段所有缺陷中未解决的缺陷的数量。
未关闭缺陷包含缺陷严重级别和时间信息。
研发中心的质量管理
质量管理（quality management）是指确定质量方针、目标和职责，并通过质量体系中的质量策划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动。
QC的七大手法
事儿一：
风险管理的数据收集和分析
事儿二：
CR需求变更的统计和分析
事儿三：
Peer Review 相关数据的收集和分析。
其他度量：
里程碑管理度量
作业流程度量
控制度量
版本管理控制度量
个人能力成熟度度量
部门成熟度度量
……
敏捷开发的度量
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。
换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
| 
