如何证明或者度量测试工作的有效性？（09-2-23）（获奖名单已公布）

默默巫

度量是改进过程的有效途径之一。通过对测试过程的度量，可以使测试过程规范化、可视化;对度量数据的分析，可以测量出测试过程的有效性及存在的问题，明确测试过程的改进方向，从而保证软件的质量。因此，对软件测试过程的度量研究具有十分重要的意义。
请问如何证明或者度量测试工作的有效性？

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	kuailederen	当当购物卡50元	2#
二等奖	qinxiaocang1202	300论坛积分	7#
三等奖	archonwang	100论坛积分	4#

kuailederen

在回答这个问题之前，我有个提议，建议以后每周一问栏目必须是原创答案，拒绝复制粘贴，只有这样才能让大家去思考，去讨论。不然就失去了这个栏目的初衷。再说，既然评奖，虽然东西不多，至少也要保证公平吧。这不是针对某个人，只是一个建议。比如 7楼的回答，他自己标出是摘抄的，我也到网上搜了以下，是100%的复制的，我想连他自己也不明白他说的这些吧。

下面来对这个问题，谈谈我的看法：如证明测试工作的有效性。

1）我们要看到我们所做的工作的存在
相信大家都经历过，自己虽然做了很多的工作，但领导却看不到。比如你一天中在不停的测试，反复的测试，但经理却以为你这一天浪费掉了。为什么？ 因为看没有看到可以看见的测试用例，没有看到你提交的大量的缺陷。
      改进：把你做的工作具体化，量化。
你无论是按照计划测试，还是自由测试，那么做了多少测试执行就要写多少测试用例，发现了问题就要及时提交缺陷。即使你完全按照已有的用例测试，也没有发现缺陷，那么你要体现你的进度和你新增加了那些测试数据，这是你工作能力的体现。你做了多少工作，下班前报告给领导吧，让他知道你做了这些事情。
2）我们要看到我们所做工作是否有意义。
      你在一个不是测试重点的地方花费了很多时间并且没有任何收获，显然你这次测试是没有意义的。



     改进：测试前要很好的理解测试计划和 测试策略，测试方案，一定保证测试进度和测试重点。
3）要证明我们的测试工作是否完全。
     测试覆盖是一个不可能完全做好的工作，需求覆盖，用例覆盖，功能点覆盖等。我们可以把已有的需求点来覆盖，但我们无法理解另外的我们所不知道的需求；我们可以写用例，但我们知道测试数据很难找全；我们可以测试看得见的功能，但那些看不见的呢？
      改进：简单的说，要建立一套有效的管理模型。
4）保证我们所做工作的效率。
       效率就是最短的时间处理最多的事情。这一点很难有标准。你能说一天执行10个用例的就比执行20个用例的效率低吗？
    改进：加强测试人员自身的能力提高，可以有效的提高效率，减少无效的工作。例如，对一个经验丰富的测试人，他可以轻易的想到最可能多的测试数据，他可以最快的定位缺陷。
5）如何来度量我们的测试工作。
         我们谁都不能证明我们繁忙了一段时间的工作做的到底有多好或者多烂，我们只能用数据说话，数据是公平的，是没有情绪的。
      改进：在测试准备阶段，我们就要定义一些标准，来限定或者指导测试的进行。比如多少的用例通过率可以说明系统的健壮程度；同样还有需求覆盖率，严重缺陷比率，缺陷单日出现率，失败用例分布，缺陷分布等。我们后期更是可以利用这些数据来做测试过程的优化工作。数据统筹工作，对于测试来说是非常有意义的。

  总之，最有效的测试工作就是用最少的工作时间，最高的工作效率，最低的测试风险来完成了测试工作。

[ 本帖最后由 kuailederen 于 2009-2-26 10:34 编辑 ]

yunxiz

测试报告吧，记录了产出，bug回归和新产生的数据对比，异常操作产生bug的规律寻找（这类需要详细记录进入test report），每个build的report都是度量，当然也会有无效而且重复的工作

archonwang

很难的课题，之前曾经看过一篇学术论文，就是关于这方面的。不过内容较深，老实说，俺当时是没看懂啦。

等有空了再说说这个问题。

==================================
2009-02-26
很同意2#的说法。

之前说过这个课题的论文，我大致找了下，如果感兴趣，需要的同仁可以自己看下（不过貌似是针对测试度量的有效性，和本问题的关系并不直接）：
《软件测试准则的有效性度量研究》 作者：清华大学 赵亮、王建民、孙家广
http://219.238.6.200/getfile?category=article&code=crad20060822&file-name=Q1162.pdf

现在说说我自己的看法：

• 度量测试的有效性，本身是很困难的，如同要证明方法的有效性一样，光从结果上判断可能会得出错误的结论。我们至少还需要从所选用的特定方法和流程上综合评判其有效性。
• 如何衡量方法的有效性？首先是各项规则规范所定义的度量数据是否可靠。往往这些数据都是经验数据，从大量的基层项目上得到，再者，衡量方法所覆盖的各项特性是否满足。如果所选用的方法不足甚至错误，那么即使得到了结果也是很枉然的。
• 接下去是关于流程。流程其实也是一种特殊方法。各项步骤，流程节点的相关附件都可以证实流程是否运作，却不能证明流程有效。通常的判断是，运作了该流程，是否可以得出相关的结论。当然，前提是在流程中所使用的各项方法都已经得到了充分验证，能保证其有效性。
• 软件测试的有效性，一方面是方法有效，一方面是流程有效，此外，还有一项就是结论有效。一般常识上讲，方法正确，流程有效，其结果必定OK——除非发生这种情况：其本身的前提就是错误的。所以，这种有效性度量还必须基于一个正确前提的基础之上进行。

以上所说的基本上都是理论内容。接下来，讲个具体点的案例。
[Case Study]：测试程序：三角形"三边理论"，对该测试度量其有效性。
测试流程：分析需求->设计案例->编写案例->执行案例并记录结果->分析结果并存档
测试规则：（略）
测试方法：黑盒测试
需求分析方法：需求规则细分
案例设计方法：边界值分析
执行方法：按案例手工执行
其他方法：（略）
附件：测试案例，测试bug记录等

度量该次测试有效性分析

• 首先度量流程有效性。评判标准：该流程是否覆盖了测试对象所需检测的各个面，这些方面的产生有赖于对对象测试需求面的分解
• 其次度量流程中所使用的方法。评判标准：这些方法综合起来，是否覆盖了测试需求面的各项测试需求细则
• 再次，检查各流程节点的附件。评判标准：整个测试工作流程中每一个节点是否有交付，是什么的交付，对交付的制作要求如何？
• 最后，检查得出结果是否有效。这个不再赘述了。

对测试工作的有效性的检查，必须严格按照PDCA的过程，严格检查各项，对检查中出现的问题，进行分析，以便于进一步优化方法，精化流程，促进各项工作有序开展。

[ 本帖最后由 archonwang 于 2009-2-26 15:23 编辑 ]

skila_fly

关注中,正面临这个问题

aman_cao

bug趋势图
用例通过率

qinxiaocang1202

  只所以摘抄是因为我觉得这段内容中有些说的特好，我来这不是为了什么奖，只是想那些像我一样对此没有太多的概念的朋友，对此能有个大概的了解，知道度量活动是怎么回事。呵呵！能学习新的东西比什么都重要！
  确实如上面的朋友所说，里面有些东西我还真不知道，不过通过每周一问我去了解了这个问题，至少在原来一无所知的基础上更进一步了。呵呵！
   看了哈二楼的分析，分析的不错，支持哈！！
控制限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）能根据需求文档写出很好的测试需求，测试用例能全面的覆盖测试需求；
   （2）测试执行时，按照测试用例能找出更多的BUG；有时在测试执行时，就能够发现测试用例有没有设计好，因为人的思维是活的，在操作至某一点时，也许会有更好的想法， 更多的测试点；
   （3）软件在用户试运行时，没有反应太多的软件问题；彻底的测试是不可能的，拿用户提出的BUG数据和以前的软件相比较，也许能更好的说明这次测试的效性；
  （4）发现的重大BUG以及关联性BUG，如果被项目经理认定了，也就是你的测试被认可了，也可以说测试是有效的；

[ 本帖最后由 qinxiaocang1202 于 2009-2-27 15:55 编辑 ]

zxgch

一直关注这个问题

生活总会更美的

觉得这个论点比较有意思，但是要做起来还是难度很大

佐伊

一些常见的衡量标准：

测试中发现的缺陷数
客户发现的缺陷数(分析：80-20分析：对缺陷类型按缺陷个数排序，找出客户发现的最多的20%的缺陷类型－－分析客户的关注点是什么？为什么客户能发现这些类型的缺陷，为什么我们没有测试出来？定义改进措施)
客户满意度调查
覆盖率：代码覆盖率、设计覆盖率（可以保证代码与设计相一致、但不能保证需求的正确性）、需求覆盖率（有助于测试设计、可用来度量测试状态、不依赖于代码）
缺陷严重程度、分布情况（80-20分析：对所有模块的缺陷密度进行排序比较，找出缺陷密度最大的20%模块－－找出质量最差的模块，采取改进措施）、存在时间、密度
Help Desk的求助数
Defect Removal Efficiency(DRE)=

Defects found in Testing/(Defects found in Testing + Defects found by Customer)*100%

这种度量方法的缺陷在于，我们并不知道到什么时候为止客户发现了所有的缺陷；并且它仍然需要考虑严重程度和分布情况的权重

摘抄iloveyouso的日志

星野猎人

newsun

关注中。。。

black_tulip

这个题目并不好。
在这里，证明一词不大合适。而度量，其实挺扯淡的。

甜甜的一天

qinxiaocang1202和佐伊分析的都蛮好
对于初学者的我算是长见识咯
呵呵

black_tulip

james shore在他的《The Art of Agile Development》一书中虽讲到过程的度量，但也是持谨慎态度。尤其是建议不要用于绩效、效果的评估、评审。

生活总会更美的

生活总会更美的

我认为如何度量测试工作的有效性，首先应该明白测试的目标或者目的是什么？能最大限度的满足测试的目标的，就能证明测试的有效性，换句话说就是要满足需求。
  我个人理解，测试的目标是尽可能的发现软件的错误或缺陷，但不是发现所有的错误和缺陷，因此有效的测试就是满足需求的测试。
   不知道，这个观点正确否？

black_tulip

第一行说得挺好，怎么到了第二行又忘了联系需求了呢？

namisang

等待达人来解决问题．

dream_cui

我们测试的目的是发现至今为止没有发现的bug，跟随着这个答案去找的话，我想应该提出一些问题：
1.测试依据的需求是不是都符合要求？
2.怎么样能发现？
2.bug的严重程度？
4..预留的bug有多少？
……
其实这个跟前期的需求调研和程序员的代码都有很大的关系，如果需求调研分析与客户的需求一致的话，这样我们按照需求进行操作就能少走很多弯路，如果需求就存在很多问题的话，就很麻烦了，所以我认为如果一个合格的测试工程师，应该先分析需求并挖掘潜在需求，争取客户意见，这个应该占有效性的50%吧；
然后就是分析流程的严重逻辑错误bug的比例；
再则应该是各个模块中存在的存储过程与调用错误问题；
还有就应该是模块的流程走通还有美观度等一些bug比例吧……
纯属个人见解，面临下班，有空再添加~
希望兄弟姐妹多提意见啦~