51Testing软件测试论坛

标题: 如何证明或者度量测试工作的有效性？（09-2-23）（获奖名单已公布） [打印本页]
作者: 默默巫    时间: 2009-2-23 10:09
标题: 如何证明或者度量测试工作的有效性？（09-2-23）（获奖名单已公布）
度量是改进过程的有效途径之一。通过对测试过程的度量，可以使测试过程规范化、可视化;对度量数据的分析，可以测量出测试过程的有效性及存在的问题，明确测试过程的改进方向，从而保证软件的质量。因此，对软件测试过程的度量研究具有十分重要的意义。
请问如何证明或者度量测试工作的有效性？

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

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


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

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

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



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

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

[ 本帖最后由 kuailederen 于 2009-2-26 10:34 编辑 ]
作者: yunxiz    时间: 2009-2-23 10:46
测试报告吧，记录了产出，bug回归和新产生的数据对比，异常操作产生bug的规律寻找（这类需要详细记录进入test report），每个build的report都是度量，当然也会有无效而且重复的工作
作者: archonwang    时间: 2009-2-23 11:02
很难的课题，之前曾经看过一篇学术论文，就是关于这方面的。不过内容较深，老实说，俺当时是没看懂啦。

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

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

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

现在说说我自己的看法：


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

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

[ 本帖最后由 archonwang 于 2009-2-26 15:23 编辑 ]
作者: skila_fly    时间: 2009-2-23 22:05
关注中,正面临这个问题
作者: aman_cao    时间: 2009-2-24 09:11
bug趋势图
用例通过率
作者: qinxiaocang1202    时间: 2009-2-24 09:32
标题: 软件测试度量的切身体会

  只所以摘抄是因为我觉得这段内容中有些说的特好，我来这不是为了什么奖，只是想那些像我一样对此没有太多的概念的朋友，对此能有个大概的了解，知道度量活动是怎么回事。呵呵！能学习新的东西比什么都重要！
  确实如上面的朋友所说，里面有些东西我还真不知道，不过通过每周一问我去了解了这个问题，至少在原来一无所知的基础上更进一步了。呵呵！
   看了哈二楼的分析，分析的不错，支持哈！！
控制限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    时间: 2009-2-24 09:45
一直关注这个问题
作者: 生活总会更美的    时间: 2009-2-24 14:31
觉得这个论点比较有意思，但是要做起来还是难度很大
作者: 佐伊    时间: 2009-2-24 14:48
一些常见的衡量标准：

测试中发现的缺陷数
客户发现的缺陷数(分析：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的日志
作者: 星野猎人    时间: 2009-2-24 15:42
标题: 关注中
作者: newsun    时间: 2009-2-25 13:30
关注中。。。
作者: black_tulip    时间: 2009-2-25 14:44
这个题目并不好。
在这里，证明一词不大合适。而度量，其实挺扯淡的。
作者: 甜甜的一天    时间: 2009-2-25 14:47
qinxiaocang1202和佐伊分析的都蛮好
对于初学者的我算是长见识咯
呵呵
作者: black_tulip    时间: 2009-2-25 14:56
james shore在他的《The Art of Agile Development》一书中虽讲到过程的度量，但也是持谨慎态度。尤其是建议不要用于绩效、效果的评估、评审。
作者: 生活总会更美的    时间: 2009-2-25 16:14
作者: 生活总会更美的    时间: 2009-2-25 16:17
我认为如何度量测试工作的有效性，首先应该明白测试的目标或者目的是什么？能最大限度的满足测试的目标的，就能证明测试的有效性，换句话说就是要满足需求。
  我个人理解，测试的目标是尽可能的发现软件的错误或缺陷，但不是发现所有的错误和缺陷，因此有效的测试就是满足需求的测试。
   不知道，这个观点正确否？
作者: black_tulip    时间: 2009-2-25 16:43
第一行说得挺好，怎么到了第二行又忘了联系需求了呢？
作者: namisang    时间: 2009-2-25 17:19
等待达人来解决问题．
作者: dream_cui    时间: 2009-2-25 17:40
我们测试的目的是发现至今为止没有发现的bug，跟随着这个答案去找的话，我想应该提出一些问题：
1.测试依据的需求是不是都符合要求？
2.怎么样能发现？
2.bug的严重程度？
4..预留的bug有多少？
……
其实这个跟前期的需求调研和程序员的代码都有很大的关系，如果需求调研分析与客户的需求一致的话，这样我们按照需求进行操作就能少走很多弯路，如果需求就存在很多问题的话，就很麻烦了，所以我认为如果一个合格的测试工程师，应该先分析需求并挖掘潜在需求，争取客户意见，这个应该占有效性的50%吧；
然后就是分析流程的严重逻辑错误bug的比例；
再则应该是各个模块中存在的存储过程与调用错误问题；
还有就应该是模块的流程走通还有美观度等一些bug比例吧……
纯属个人见解，面临下班，有空再添加~
希望兄弟姐妹多提意见啦~
作者: rolei    时间: 2009-2-25 18:17
标题: 测试度量的标准是什么？
－－－－确认了测试度量的标准。
也就是先确认要达到什么标准，以实际的情况为基础，确认测试的各项度量指标；
有效或是无效，结果数据说了算。

确认了标准，然后在收集数据的基础上统计分析，最终确认度量目标达成的情况。

同时对度量标准进行周期性的修正和改进。
作者: Jackc    时间: 2009-2-26 15:04
好难的问题，云里雾里的，就像一个罪犯对法官说：“偶是冤枉的，偶无罪。”法官就说：“请举证。”于是罪犯罗列出了N多证据，什么无作案时间啊，无作案动机啊，与被害人不认识啊等等...法官又说：“请证明证据的真实性！”....

还是坐着看有没有人能说明白吧，偶CMM/ISO都没仔细看过，可说不好这个东东~

[ 本帖最后由 Jackc 于 2009-2-26 15:07 编辑 ]
作者: 雅丹咔咔    时间: 2009-2-26 16:39
测试做不到的：
1.无法切实证明测试为产品、项目节约了多少成本、规避了多少风险，减少了多少损失，提升了多少客户满意度！
2.没有一个类似软件的看得到、用得上的东东，只有一堆堆的方案、用例、报告、总结，都是说明问题的！上级领导只是了解了开发组改了多少bug，严重级别的bug多少，会不会影响发布！
我想这也是度量的难点，虽然CMMI中定义的度量也在不同的过程域中收取度量数据来说明项目所存在的问题，但是针对测试的度量没有几个公司能明白的说出来（可能也是我这个井底之蛙的见解吧）。
等待高人见解！
作者: sealyna    时间: 2009-2-27 11:59
我任为什么都是一步步积累起来的，不可能一下子这个全面，如果只是为了度量，而且影响了效率，那也不行，我现在想的就是做好自己的事情，然后，再有空，就是更加完shan流程，哪怕我以后不在这个公司了，也许等这个公司规范起来了，我可能不在这个公司了，但是给公司创造价值的时候，也是提高了自己的能力。度量，其实如果有高度的自觉性，还需要度量吗，当然我知道林子大了，是需要的，反正还是一个矛盾体
作者: chengxq    时间: 2009-2-27 15:34
度量软件测试过程的有效性
1.软件测试是否有计划
在软件测试计划中，要明确测试的范围，测试的过程，测试进度，以及测试过程沟通，特别是明确测试阶段每个活动的输入准则和输出准则，已经根据以前的历史数据来制定项目组各个过程的品质目标，如果没有将这些在测试计划中体现，那我们在项目实际过程中，做的也只是收集数据，而不是度量数据，就不能对测试的有效性进行真正的判断。我们所有的度量分析，很多程度上是依赖于好的计划，所以好的俄时计划是基础
当然我们在测试计划中也可以添加对测试有效性的判断，测试有效性范围太广了，我们需要进行量化和细化，通过对这些量化和细化的数据（下2）来对测试总的有效性进行判定，
2.根据测试计划度量进行测试有效性的判断
我们根据测试的活动度量数据，如：我们在开始测试的时候，判定人员的技能，对人员技能进行相应的判断，对测试输入的工作产品进行相应的判断，如测试需求进行review的时候，看找出的缺陷率，来判定测试需求的正确性，如，写测试case，我们进行review的时候，我们看找出的缺陷率，我们在执行测试用例的时候，我们看测试用例的有效性，如1000个case发现了多少问题，如，看测试case 的消化率，1000个case需要多少时间，这个时间是否正常，我们在执行测试的时候，发现每个画面发现的bug数，或发现总的缺陷数，我们对缺陷进行分类，看在一定的时间内发现重大的缺陷为多少，占的比率为多少等等，确定我们的过程，度量我们的过程，同时现在我遇到的很多的公司，很多都是先让开发人员测试画面，等他们确认没有问题在让测试人员去测试，我们可以通过，我们发现的测试bug数除以我们发现的缺陷数加上开发组发现的缺陷数（测发现bug/（开发发现bug+测发现bug））来判定我们测试的有效性，我们甚至可以对配置管理进行数据收集来判断测试有效性，因为测试肯定也有版本控制，如果我们不对版本控制，那我们也不能说我们测试是有效的，当然收集数据的方法有很多，网上应该也有很多，在这就不能废话了，我们在统计数据的时候，我们必须要清楚，我们的目的是什么，我们收集什么数据，何时收集等问题
3.对测试过程中，发现的管理过程改进
我们对上2的数据收集后，发现测试过程中，主要的问题点，我们需要花费必要的资源对过程进行改进，来提高我们的测试效率，但是前提是我们有度量，没有度量没有控制，然后我们根据改进后的结果进行必要的数据收集，来判定改进后的效果
作者: wuchunying    时间: 2009-2-27 15:59
证明测试工作的有效性：在项目或产品的周期内，测出了BUG,还测出来很多危害项目或产品功能、性能的BUG，那测试工作就是有效的。(现在的一个项目或产品不会没有BUG吧，要是真没有就是开发把测试的工作也干了，以后真不需要测试这个职位了)
       度量测试工作的有效性就难说了，1、要说在一个时间段内发现高级别的BUG越多，就越有效是片面的，BUG的多少很多时候取决于开发水平和公司给的开发进度。2、光凭写了多少测试用例或执行了多少用例，也不全面，写的测试用例多，但是多不一定就精。而且用例执行也有难易，所以不可能每天都执行相同量的用例。
作者: xiahuaoxiang    时间: 2009-2-28 00:12
过来看看
作者: angelna    时间: 2009-2-28 20:08
可以在QC里面定置一些质量的属性,可以设置如下:

1、BUG来源：SRS，HLD，LLD，CONDING，TESTING
2、缺陷严重程度：致命、严重、一般、建议
3、用例优先级：高，中，低
4、发现的BUG版本：1.0,2.0,3.0
5、缺陷状态分布：关闭，遗留，撤消
6、用例属性：正面，反面
对以上属性进行统计，这样就可以综合评价
作者: lifr    时间: 2009-3-1 22:46
原帖由 默默巫 于 2009-2-23 10:09 发表
度量是改进过程的有效途径之一。通过对测试过程的度量，可以使测试过程规范化、可视化;对度量数据的分析，可以测量出测试过程的有效性及存在的问题，明确测试过程的改进方向，从而保证软件的质量。因此，对软件测试过 ...



这个问题本身的提法我觉得有一些问题。作为一名工程师，我比较喜欢讨论和分析一些具体的东西，以此为出发点，我斗胆向楼主提出我的一点想法，考虑不周之处，还请指教。
1） 题目太大
这里的”测试工作‘到底是指什么？如果是指测试的整个过程，也就是从分析需求开始到写test report为止，每个阶段的工作有效性的度量的话，那么这个题目也太大了。要么泛泛而谈，要么只能是长篇大论，几句话肯定表达不清楚，

如果按照我自己的理解做一个限制，特指“测试执行过程”中的有效性的量度，那么问题就变得简单多了。按照我在实践中的体会（不是理论也不是XXX标准），我觉得aman_cao简单的两句话其实最直接准确，
    bug趋势图
    用例通过率

2）缺少例子
我还想提一个建议，就是这类技术问题最好有一个现实的例子。我想这里的大多数都是具体干活的工程师，做理论的应该很少，枯燥的什么XXX标准肯定也不太感兴趣。所以一个实际的例子更方便讨论，更能引导大家贴出自己项目是怎么来量度的，互相参考，我想是很有意义的。
以这个问题为例，最好能举出在一个实际的例子里，人们是如何来做测试工作有效性的度量的，有什么缺点和分析大家可以一起来分析。弄清了一个例子，其他我想也可以触类旁通了。
作者: blackn72    时间: 2009-3-2 15:04
在我看来，有效应该包含了两个方面：一是在一定时间内找出尽可能多的BUG，另一个就是尽可能的减小在用户手里出现问题的可能性，也就是说用户反映的问题越少，就证明测试越有效。
第一点主要是体现在测试报告中的，比如每天执行了多少测试用例，发现了多少BUG，有多少BUG是严重的。这一点我觉得是测试人员用来证明自己工作成绩的一种方式。
第二点就比较难以衡量，这和许多因素等都有关系。在实际使用过程中，也许长期使用都只是一些小问题，也许一个偶然的操作就出现了一个致命问题。但不管出现什么样的问题，都会使本次测试的有效性打了折扣。当然，这不是说这就是测试人员的问题，可能是需求不明确，分析不全面，测试数据环境等原因，但至少说明测试有需要改进的地方。我觉得这种度量是一个长期的过程，而且需要具体分析，比如，比较用户发现的问题和测试过程中发现的问题，看看测试中发现的问题是否真的有效。
作者: carolin    时间: 2009-3-2 22:52
觉得这个论点比较有意思
作者: 星野猎人    时间: 2009-3-21 16:13
标题: 工作体验中
对于2楼 说的 感觉 还是比较 实在



欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2