软件质量可视化的简单探讨

非猫

测试人员的囧境：在大多数的项目中，测试人员是软件质量的责任者;测试是版本发布前的最后一个环节，发版=加班这个即将成为恒等式;在项目或整个SOP中，软件测试处于最后一小时工作的那种;测试人员程度着这样一种压力： 得尽快的证明软件可以发布，但实际上，他并没有足够的时间或者足够的测试让自己相信这点。如果发布的版本出了问题，大家就会对测试人员说：你们为什么不能发现那些BUG? BUG不是测试人员所建立，但是却承担着BUG出现后的责任。

这种境况需要改善，首先我们得意识到：1）测试的工作跟开发并不对立，测试不是破坏开发的成果，而是协助他们更加的完善，发现他们的盲点，从另一方面讲，也会促进开发提高技术; 2）软件质量应该是整个团队职责，而不仅仅是测试人员，其他人员在软件质量形成的过程中可以起到更积极的角色。

要做到这点，首先，得让大家明白软件质量是怎样的？这点测试人员应该是最清楚的，所以要时不时地想其他人员传递产品的质量信息;有经验的测试人员可以试着想一些创新的方式来传递软件质量的信息。


报告测试深度和主观的质量
我们都知道，很难简单的说质量是高还是低;比如，做了一遍简单的测试，都通过了，没有bug，这个是质量高还是低？那一个团队应该怎样选择报告这俩方面的信息：他们能完成的测试深度和主观评估。

对于深度来说：可以试着设定从1到3或者5个数字，1呢意味着浅显的测试（比如基本功能）5代表测试的各个方面包括边界和一些极端的条件。哪一级做哪些事情这个都可以讨论的。当这些确定后，（如果项目中有多个QA）每个人根据这些标准和项目的情况，同时用手亮出自己打的数字...如果有人所表示的数字不一致，则需要讨论，比如说我选择1，大家选择3，那我们就要讨论一下为什么会这么选择，讨论过后，再投票进行选定...如果讨论不一致，则取低位数。

可以使用相同的方法来取得质量信息，大拇指，最高。。依次排下去中、低;

{这种快速的合作练习有利于让测试团队的人对测试深度和质量有个普遍的了解;}


在发布的时间，提供新功能的质量报告，一般情况在，在开发结束后会提供一个测试版本，在测试版本到正式版本之间，我们可以用以上的指标为每个功能标示测试深度和质量;

测试团队经常会抱怨我们没有足够的时间进行全面测试，但是这些抱怨并没有得到解决;现在这个抱怨就没有必要了，测试深度可以很好的体现这点，也是时间让团队成为一整体来看到我们的测试情况~~，一般情况下，看到这些实际的数据，开发人员会尽可能的在编码结束后给测试留足够的时间~~这点是有理由相信的。

定期报告整体产品的质量，
开发在继续，产品的功能不断增加，测试人员继续努力地测试着新功能，并且进行着回归测试;继续保持像团队通知他们对产品的质量评估;定期报告可根据实际情况进行;

保持BUG数量的可见度

不能用发现的BUG的数量来评估软件质量。 比如，测试深度较低就返回少量的bug，而高深度的测试一般会返回更多的BUG. 即使是少量的BUG,一个评估也会显示低质量：我并没有测试太多，但是我测试的都成功了。

BUG的可见性可以用图标的方式来显示，一般bug的数量是个正态分布，当开发开始修正bug的时候后那条曲线的增长速度会变得非常缓慢。保持低BUG的增长率对于开发来说才是高绩效的一个重要表现。而且他们也不希望自己的bug数量被大家看见，另外高bug量会影响测试团队对于质量的评估;

到版本发布的时候，项目经理最终决定版本是否发布，但是整个团队至少知道即将发布的版本的质量;低水平或适度的测试可能会给发布的版本带来风险，但是现在这个风险是可见的。

事后检验（也是测试效率的一个算法）

如果说前提提供的报告是主观所得，在版本发布后就可以进行进一步的评估：用未发现的bug数量与已测的进行比较，当然再加上每个bug的权重，如下：

(（SUM(已发现BUGj*严重程度j)-SUM(未发现BUGk*严重程度k)）/SUM(所有BUGi*严重程度i))*100%

为质量顶个区间：比如高：95%-100%：高 85-95% 中  85%以下低，或者根据实际情况进行设定


这是块砖~~有兴趣的可以继续抛~~~

[ 本帖最后由 非猫 于 2009-3-13 19:02 编辑 ]

xinqidian123

测试人员的囧境。。。。