软件系统质量的评判标准

影响软件系统质量的因素有多种，对它的评判标准也不能太单一。我们既可以用外部的表面的的数据，比如Bug；也可以用内部的潜在的数据，比如每个Bug的修改成本。

 

这有一个例子：

A产品，提交测试之后发现了比较多的Bug，但开发人员可以迅速修正，并没有带来其他的Bug。

 

B产品。虽然第一次测试发现的Bug比较少，但修复的时间却很长，并且回归测试带来了其他的bug。

 

显然A产品的质量要优于B产品。我们知道原因，那就是A产品的代码质量和设计质量要优于B产品，所以它才可以在较短的时间内解决问题，给人以基础牢固，结构健壮的感觉。

 

软件系统的质量，要依赖于需求分析的质量（比如有无逻辑漏洞等），设计/代码质量（修改Bug的时间，是否会产生新的Bug等），测试质量（发现bug的数量和重要程度），以及文档和培训质量（按照规定的方式操作）等。

 

我们把这些标准分为两类，外部标准和内部标准。

外部标准：

    1. 给客户带来的损失。比如数据错误，系统宕机。把损失换成金钱，除以此系统本来可以赚的利润，达到一个百分比：

标准1： 客户损失金额/利润

           说明：得到这个数据可能比较困难，现实有很多情形，我们可以灵活处理。一般的小问题客户并不去计算损失，只要我们及时的把问题解决了就行了。然而我们总是要付出人力成本的,这些成本当然会降低公司利润。

    2. 客户的抱怨。比如用户体验差等。

               标准2： 负面反馈/所有反馈

       说明：这个是不能量化的东西。我们只求一个估计的值，比如从用户满意度调查中取得数据。Bug并不一定能产生负面反馈，比如当你的系统用户体验很好，某些地方超过用户期望，用户对那些次要的缺陷也会很宽容了。

    3. 客户报告的Bug。

               标准3： 客户报告的Bug/所有发现的Bug

       说明：这里可以督促我们测试人员在上线前尽可能的把所有Bug找出来。

内部标准：

1.       设计和代码质量。

       标准4：修复Bug成本/开发总成本

   说明：这里的成本一般指“人/日”等数据。好的设计和代码，改起来会很快，那么这个比值就会很小。这个指标另外也可以督促开发人员尽可能的在测试之前消除Bug，因为Bug越少，这个比值也会越小。

2.       需求分析质量。

       标准5：需求变化量/需求总量

        说明：这里的“需求变化”指由于公司内部的需求分析人员失误而造成的更改。关于如果确定这个“量”，应该结合公司实际来确定。

最终的数值由上面5个比值而来，根据实际情况，赋予不同的权重。假如最后加起来的值为x, 则：

       Q=(1-x)*100

Q值越大，质量越好。最理想的情况是100分，最坏的分数会是一个负数。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/kevinkevin/archive/2010/04/05/5452381.aspx