测试度量的标准是什么？
－－－－确认了测试度量的标准。也就是先确认要达到什么标准，以实际的情况为基础，确认测试的各项度量指标；
有效或是无效，结果数据说了算。
确认了标准，然后在收集数据的基础上统计分析，最终确认度量目标达成的情况。
同时对度量标准进行周期性的修正和改进。 好难的问题，云里雾里的，就像一个罪犯对法官说：“偶是冤枉的，偶无罪。”法官就说：“请举证。”于是罪犯罗列出了N多证据，什么无作案时间啊，无作案动机啊，与被害人不认识啊等等...法官又说：“请证明证据的真实性！”....
还是坐着看有没有人能说明白吧，偶CMM/ISO都没仔细看过，可说不好这个东东~:lol
[ 本帖最后由 Jackc 于 2009-2-26 15:07 编辑 ] 测试做不到的：
1.无法切实证明测试为产品、项目节约了多少成本、规避了多少风险，减少了多少损失，提升了多少客户满意度！
2.没有一个类似软件的看得到、用得上的东东，只有一堆堆的方案、用例、报告、总结，都是说明问题的！上级领导只是了解了开发组改了多少bug，严重级别的bug多少，会不会影响发布！
我想这也是度量的难点，虽然CMMI中定义的度量也在不同的过程域中收取度量数据来说明项目所存在的问题，但是针对测试的度量没有几个公司能明白的说出来（可能也是我这个井底之蛙的见解吧）。
等待高人见解！ 我任为什么都是一步步积累起来的，不可能一下子这个全面，如果只是为了度量，而且影响了效率，那也不行，我现在想的就是做好自己的事情，然后，再有空，就是更加完shan流程，哪怕我以后不在这个公司了，也许等这个公司规范起来了，我可能不在这个公司了，但是给公司创造价值的时候，也是提高了自己的能力。度量，其实如果有高度的自觉性，还需要度量吗，当然我知道林子大了，是需要的，反正还是一个矛盾体 度量软件测试过程的有效性
1.软件测试是否有计划
在软件测试计划中，要明确测试的范围，测试的过程，测试进度，以及测试过程沟通，特别是明确测试阶段每个活动的输入准则和输出准则，已经根据以前的历史数据来制定项目组各个过程的品质目标，如果没有将这些在测试计划中体现，那我们在项目实际过程中，做的也只是收集数据，而不是度量数据，就不能对测试的有效性进行真正的判断。我们所有的度量分析，很多程度上是依赖于好的计划，所以好的俄时计划是基础
当然我们在测试计划中也可以添加对测试有效性的判断，测试有效性范围太广了，我们需要进行量化和细化，通过对这些量化和细化的数据（下2）来对测试总的有效性进行判定，
2.根据测试计划度量进行测试有效性的判断
我们根据测试的活动度量数据，如：我们在开始测试的时候，判定人员的技能，对人员技能进行相应的判断，对测试输入的工作产品进行相应的判断，如测试需求进行review的时候，看找出的缺陷率，来判定测试需求的正确性，如，写测试case，我们进行review的时候，我们看找出的缺陷率，我们在执行测试用例的时候，我们看测试用例的有效性，如1000个case发现了多少问题，如，看测试case 的消化率，1000个case需要多少时间，这个时间是否正常，我们在执行测试的时候，发现每个画面发现的bug数，或发现总的缺陷数，我们对缺陷进行分类，看在一定的时间内发现重大的缺陷为多少，占的比率为多少等等，确定我们的过程，度量我们的过程，同时现在我遇到的很多的公司，很多都是先让开发人员测试画面，等他们确认没有问题在让测试人员去测试，我们可以通过，我们发现的测试bug数除以我们发现的缺陷数加上开发组发现的缺陷数（测发现bug/（开发发现bug+测发现bug））来判定我们测试的有效性，我们甚至可以对配置管理进行数据收集来判断测试有效性，因为测试肯定也有版本控制，如果我们不对版本控制，那我们也不能说我们测试是有效的，当然收集数据的方法有很多，网上应该也有很多，在这就不能废话了，我们在统计数据的时候，我们必须要清楚，我们的目的是什么，我们收集什么数据，何时收集等问题
3.对测试过程中，发现的管理过程改进
我们对上2的数据收集后，发现测试过程中，主要的问题点，我们需要花费必要的资源对过程进行改进，来提高我们的测试效率，但是前提是我们有度量，没有度量没有控制，然后我们根据改进后的结果进行必要的数据收集，来判定改进后的效果 证明测试工作的有效性：在项目或产品的周期内，测出了BUG,还测出来很多危害项目或产品功能、性能的BUG，那测试工作就是有效的。(现在的一个项目或产品不会没有BUG吧，要是真没有就是开发把测试的工作也干了，以后真不需要测试这个职位了)
度量测试工作的有效性就难说了，1、要说在一个时间段内发现高级别的BUG越多，就越有效是片面的，BUG的多少很多时候取决于开发水平和公司给的开发进度。2、光凭写了多少测试用例或执行了多少用例，也不全面，写的测试用例多，但是多不一定就精。而且用例执行也有难易，所以不可能每天都执行相同量的用例。 过来看看 可以在QC里面定置一些质量的属性,可以设置如下:
1、BUG来源：SRS，HLD，LLD，CONDING，TESTING
2、缺陷严重程度：致命、严重、一般、建议
3、用例优先级：高，中，低
4、发现的BUG版本：1.0,2.0,3.0
5、缺陷状态分布：关闭，遗留，撤消
6、用例属性：正面，反面
对以上属性进行统计，这样就可以综合评价 原帖由 默默巫 于 2009-2-23 10:09 发表 http://bbs.51testing.com/images/common/back.gif
度量是改进过程的有效途径之一。通过对测试过程的度量，可以使测试过程规范化、可视化;对度量数据的分析，可以测量出测试过程的有效性及存在的问题，明确测试过程的改进方向，从而保证软件的质量。因此，对软件测试过 ...
这个问题本身的提法我觉得有一些问题。作为一名工程师，我比较喜欢讨论和分析一些具体的东西，以此为出发点，我斗胆向楼主提出我的一点想法，考虑不周之处，还请指教。
1） 题目太大
这里的”测试工作‘到底是指什么？如果是指测试的整个过程，也就是从分析需求开始到写test report为止，每个阶段的工作有效性的度量的话，那么这个题目也太大了。要么泛泛而谈，要么只能是长篇大论，几句话肯定表达不清楚，
如果按照我自己的理解做一个限制，特指“测试执行过程”中的有效性的量度，那么问题就变得简单多了。按照我在实践中的体会（不是理论也不是XXX标准），我觉得aman_cao简单的两句话其实最直接准确，
bug趋势图
用例通过率
2）缺少例子
我还想提一个建议，就是这类技术问题最好有一个现实的例子。我想这里的大多数都是具体干活的工程师，做理论的应该很少，枯燥的什么XXX标准肯定也不太感兴趣。所以一个实际的例子更方便讨论，更能引导大家贴出自己项目是怎么来量度的，互相参考，我想是很有意义的。
以这个问题为例，最好能举出在一个实际的例子里，人们是如何来做测试工作有效性的度量的，有什么缺点和分析大家可以一起来分析。弄清了一个例子，其他我想也可以触类旁通了。 在我看来，有效应该包含了两个方面：一是在一定时间内找出尽可能多的BUG，另一个就是尽可能的减小在用户手里出现问题的可能性，也就是说用户反映的问题越少，就证明测试越有效。
第一点主要是体现在测试报告中的，比如每天执行了多少测试用例，发现了多少BUG，有多少BUG是严重的。这一点我觉得是测试人员用来证明自己工作成绩的一种方式。
第二点就比较难以衡量，这和许多因素等都有关系。在实际使用过程中，也许长期使用都只是一些小问题，也许一个偶然的操作就出现了一个致命问题。但不管出现什么样的问题，都会使本次测试的有效性打了折扣。当然，这不是说这就是测试人员的问题，可能是需求不明确，分析不全面，测试数据环境等原因，但至少说明测试有需要改进的地方。我觉得这种度量是一个长期的过程，而且需要具体分析，比如，比较用户发现的问题和测试过程中发现的问题，看看测试中发现的问题是否真的有效。 觉得这个论点比较有意思
工作体验中
对于2楼 说的 感觉 还是比较 实在:)
页:
1
[2]
