软件测试度量的切身体会

控制限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),这样成本不高但见效很快，从而赢得开发人员和管理人员的支持。不过该方法缺乏系统性，需要组织本身来提出一整套系统的、适合于组织自身实际的度量指标体系。
估计与度量的差别：估计是事前预测；而度量则是进行事中相关数据收集和事后分析并采取相应措施。
开展软件度量活动需要注意的事项：首先，度量要争取得到高层支持；其次，度量总的宗旨是理解，而非评估，所以度量决不能针对个人，应针对过程；再次，度量时要做到目标明确、方法得当，度量计划要明确、完整；最后，切记使得过程度量制度官僚化。
随着软件过程概念的提出，软件工程从以产品为中心过渡到以过程为中心。基于好的软件过程可以获得搞质量的软件产品这一假设，通过实施软件过程改进来不断提高软件质量已成为软件工程领域公认的准则。
国内中小软件企业特点(1)人员少(2)资金不足(3)软件过程不明显，甚至没有明确定义的软件过程(4)企业从事的软件生产呈现明显的领域特征(5)人员间的沟通方便。

如果你是在做管理或曾经做过测试管理，那么你会发现流程的把握公司只会前期很短的耐心时间等待你，实际公司原有的产品质量在你测试后是否能有期望中的提高，是否达到减少成本目的是公司最终衡量你的标准。
      当只有存在一个达到了一定战绩和明显改善了公司产品质量的测试团队时，新成员的考核可以建立在此基础上。但新成员演变成了熟练技术员，衡量他的将是出去的产品用户反馈回的BUG幼稚程度。

呵呵，说到同感处，又情不禁再发表一点自己的观点：
      测试大家都可以认同的一点是在成品测试阶段遗留的bug测试工作如果理想应该做到“查找到这些BUG的80%”，而且产品交付后再默许遗留的20%以下的BUG显然级别较高的数量应该是很少量；
    因此公司如果够规范可以基于此做出绩效考核的几个指标来衡量测试人员的工作，显然如果在正式产品运行后用户反馈回级别较高的BUG教多，或级别不高但数量可观，那么我们认为测试的工作效率是比较低的。
    呵呵，这一点我们在上初中时老师就教会了我们如何计算一级方程式，我们设定现在我们测出的总有量为80%，那么我们可以得到一个假设的总值，当然也可以算出剩余的20%。
      剩下我们需要去划定几个指标，就是超出20%的量有多少，质如何；可根据公司具体情况而定。

我们公司的处理方式：一个软件或者一个系统在两个版本测试之后，达到一个比较稳定的状态，如果负责系统某个模块测试的测试人员，在第二个版本测试已经不能提出质量较高的bug时，则进行交换，由其他的测试人员接手该模块，如果在版本没有更换的情况下，发现了级别较高的bug，那么我们会根据该bug的出现频率，出现时机判断是否应该更早提出，这样可以判断前一测试人员的工作效果，另外，我们还根据测试人员的沟通能力，工作速度，工作质量进行评判，还有一个长期的追踪就是客户反馈， 我们在出版本的时候，最终定版本的相关测试人员都要签字的，这样可以长期的跟踪测试人员的工作质量。

这篇是老贴子了。我来说说。
一线的测试员工一般无法参与到整个产品的流程中去，只是当产品转测试的时候，才能真正开始开工。一般由测试经理参与整个产品的流程中去。
既然测试执行者只做测试这部分，那么就该把这部分当做员工的考评标准。比如发现的BUG数，发现BUG的质量。测试过程中员工的主观能动性，包括是否提出了自己的看法，该看法对改进测试工作是否有效，员工是否有自己的心得体会，是否善于总结小结等。

衡量测试工作的绩效关键是看测试环节上对产品质量控制的好坏。测试有很多种，在SP的开发模型中测试人员和开发人员的界限已经不是很明确了。但是主要还是看漏测率。即产品开发周期中发现的问题（产品发布前）和网上问题（产品发布后）的比例。如果产品发布后还是一堆问题担负首要责任的必然是测试

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