测试度量的切身体会

控制限36的制定遵守是切比雪夫不等式，具体见笔记和书。有了理论基础。
　　有一个想法，X的平均值不按照树上的求发，完全按照概率的算法，算出来的结果式不是更科学。即，按照概率书上直接求数学期望和方差的方法。不知道能不能算先进。理论依据到是有的，就是也还是大数定理。
度量中遇到的问题：
　　1. 收集测试用例文档页数不科学。因为在测试小组编写测试用例是在Excel下面，基本上一个用例的编写占用一格。因此，考察测试文档的有效性跟测试用例的有效性雷同，所以文档的数量度量不再考虑。
开题报告中的问题：
　　1.偏题。论文研究的主要目的是促进研发。方法，找测试、开发、产品质量的关系。从测试度量角度，度量测试，度量开发，度量产品质量。
 
实施度量活动的一些经验教训：
　　1.必须获得高层领导的支持，这是实施度量计划的基础
　　2.成立专门的数据分析小组，成立可以由组织层的数据分析人员和项目经理构成
　　3.在度量开展之前必须定义度量目标
　　4.3级中，由于大量文档的使用，软件工程室个人的效率会有比较大的下降。因此，充分利用工具来减轻手工劳动强度将有利于软件开发过程的运用于推广。
　　5.度量系统的能力，是和组织软件过程成熟度关系密切。因此，在软件过程还不成熟、混乱的情况下，需要制定简单可行的度量计划。随着软件过程的逐步成熟，再根据需要逐步提高质量系统的能力。
　　6.长期来看，必须把过程管理建立在数据的基础上，即使对于CMM2级来说，尽早的积累数据，也是非常有用的。
　　一点想法，可以将度量分析出来的稳定可控的数据作为评测工作的标准。
实际操作步骤
　　1.确定当前的评审数据值在控制图上的位置。
　　2.如果缺陷密度出于UCL和LCL之内，这就意味着被评审对象的质量可以被接受，修改后可以进入下游活动
　　3.如果缺陷密度高于UCL，这就意味着被评审的对象的质量不能被接受，采取的措施是修改后重新评审
　　4.如果缺陷密度低于LCL，这就意味着被评审对象中发现了过少的缺陷，这有两种可能：
　　（1）评审效率太低，需要重新评审；
　　（2）被评审的质量可能由于某种原因，特别高，这种情况下就不必再评审了。
　　在第四中情况下，评审小组需要结合自己的经验来判断是否需要重新评审。
　　在执行过程改进之后，比如开展同行评审主席培训，可以使用一个过程改进因子，比如开展这项培训可以提高同行评审对象质量20％。这样，就可以获得新的过程能力：
均值（新）＝均值（旧）×（1－20％）
UCL（新）＝UCL（旧）×（1－20％）
LCL（新）＝LCL（旧）×（1－20％）
　　然后，将培训后开展的培训数据点，打在新的控制图上，观察点的位置。如果大量点落在均值之上，说明培训的效果没有达到预计的提高20％的目标，即高估了培训的效果。这时就要根据新的数据来重新获得过程能力。如果大量点落在均值之下，说明培训的效果达到并超过预计的提高20％的目标，即低估了培训效果，这时也要根据新的数据点来重新获得过程能力。总之，只要新的数据点出现明显异常或者某种模态，就说明过程处于失去控制状态，需要做进一步的调查来了解实事和真相。
软件过程模型和标准
　　1.目标/问题/度量模型GQM(Goal/Question/Metric)
　　2.统计过程控制模型SPC(Statistical Process Control)
　　3.ISO/IEC 15939 是一个有关软件度量过程的国际标准
　　4.实用软件度量模型PSM(Practical Software Measurement)是对ISO/IEC 15939的具体实现。其描述了2个模型：度量过程模型MPM(Measurement Process Model)和度量信息模型MIM(Measurement Information Model)
<I-C-M模型>，模型基于"Plan-Do-Check-Act"管理方式
　　软件度量概念从1968年被正式。软件度量的实质是将软件的属性数量化。
　　软件度量的主要建模方法：其中统计方法类中主要是回归分析（以多元线性回归较常用）
　　Basili所提出的目标/问题/度量(Goal/Question/Metrics,G/Q/M)模型，针对性强灵活性好，且更为重要的是，它可以从小型开始(Start Small),这样成本不高但见效很快，从而赢得开发人员和管理人员的支持。不过该方法缺乏系统性，需要组织本身来提出一整套系统的、适合于组织自身实际的度量指标体系。

原文转自：http://www.ltesting.net