这才是最佳的软件质量定义！

虽然我们常把软件质量挂在嘴边，但是软件质量的内涵我们并不清楚。

关于软件质量经常听到有两种定义：

• 质量定义1：软件质量意味着最终软件产品符合软件需求

• 质量定义2：软件质量意昧着软件产品具有很好的可靠性、可移植性及诸多其他特性

这两种定义貌似合理，实际上都不是好的软件质量定义。

对于定义1的问题，主要表现在以下三个方面：

1. 循环论证的问题

这个定义把需求当作衡量软件质量的标准，实际上软件需求的错误非常多。据统计，软件需求缺陷占全部软件缺陷的20%左右。从某种意义上说，需求质量也是软件质量的一部分，这就存在循环论证的问题。

在软件需求当中总是夹杂着各种“有毒”需求、残缺需求和过度的需求，这使得软件产品满足需求就是高质量的定义看起来像个笑话。

著名的“千年虫”问题，实际上就是用户的一项特殊需求：用户要求在软件中使用两位数字的日期字段。

1. 软件开发期间无法控制质量

这个定义意味着评估软件的质量要等到软件产品开发完成之后，那么开发期间的软件还具不具备质量属性？开发期间没有质量属性还怎么控制质量？控制质量如果只靠产品开发完成之后的测试，那会给软件项目增加多少成本？

1. 有些创新的软件可能根本就没有用户

比如第1个电子表格，最早的Web搜索引擎，这些应用都是开发者为解决某个自己想要解决的问题创造出来的，而不是根据用户需求开发出来的。

定义2把软件质量定义为一种特性，包括：

1．可扩展性 2．兼容性 3．可扩张性 4．灵活性 5．互操作性 6．可维护性 7．可管理性 8．可修改性 9．可操作性 10．可移植性 11．可靠性 12．可伸缩性 13．可生存性 14．可理解性 15．可用性 16．可测试性 17．可追踪性 18．可验证性

但是，站在用户的角度来看，只有可靠性，可测试性与质量有关。其他特性或者与质量无关(如可移植性)或者只关乎开发团队的利益与用户无关(如可维护性)。大多数特性根本不能解决困扰客户的质量问题。

如果把这个定义应用到微软的操作系统上，可能会有超过一半的特性不适用。具体分析见下表：

那么什么样的定义才是好的软件质量定义呢？

《软件工程最佳实践》一书中给出了切实可行的软件质量定义需要具备的6个基本特征：

1. 软件应用运行之前，软件质量应该是可预测的。

2. 软件质量需要囊括所有可交付物而不仅仅只包括代码。

3. 软件质量应该在开发期间可度量。

4. 软件质量应该在软件发布给客户之后仍然可度量。

5. 对客户来说，软件质量应该是显而易见的，且获得客户认可。

6. 在发布之后的维护阶段，软件质量应该仍然是持续的。

并由此给出了自己的质量定义：

质量定义3：质量就是软件产品中不存在会导致软件停止工作或行为不正确的缺陷

以及完美的质量定义包括的9个方面：

1. 质量意味着软件被部署时的低缺陷水平，理想地接近零缺陷。

2. 质量意味着高可靠性，或者没有宕机、行为怪异、非期望结果或性能迟缓等现象。

3. 质量意味着当对软件应用及其功能进行调查时的高用户满意度水平。

4. 质量意味着满足大多数客户或用户正常运作需要的功能集合。

5. 质量意味着良好的代码结构和清晰适度的注释密度，当试图修复旧缺陷时最大限度地减少不良修复和意外引人新错误，也有利于软件添加新的功能。

6. 质量意味着当问题发生时有效的客户支持，客户联系支持团队和获取帮助的难度最小。

7. 质量意味着快速修复已知缺陷，特别是高严重性缺陷。

8. 质量意味着支持由软件开发者提供结软件客户有意义的担保和保证。

9. 有效质量定义应该促使质量不断提高。这意味着软件质量需要足够严格的定义，以使质量提高和下滑都可识别．对平均水平也一样。如果质量定义不能反映软件质量的变化或改善，那它的价值非常有限。

书中对这三种定义包含了质量因素进行了评分，见下表：

在这些质量因素中，得分为10分的在提高软件质量方面已成为最有效的定义，得分高于7分的是有用的，得分低于5分的没有任何数据表明它可以改进软件质量。

综上所述，可以得出以下结论：

1. 定义1非常危险，除非那些不正确、毒性或危险的需求都被消除掉。

2. 定义2中绝大多数特性难以度量，而且很多特性意义不大。

3. 定义3可以帮助我们改善软件质量。

这正是：

满足需求很可笑，诸多特性用不着。

改善质量是标准，如此定义才最好。