《软件工程—产品质量》（GB/T 16260-2006）中规定对软件的每个质量特性与子特性都有定义：一、功能性：是指当软件在指定条件下使用，软件产品满足明确和隐含要求功能的能力。适合性：是指软件产品与指定的任务和用户目标提供一组合适的功能的能力。准确性：是指软件产品具有所需精确度的正确或相符的结果及效果的能力。互操作性：是指软件产品与一个或多个规定系统进行交互的能力。保密安全性：是指软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，但不拒绝授权人员或系统对其的访问。功能依从性：是指软件产品依附与同功能性相关的标准、约定或法规以及类似规定的能力。二、可靠性：在指定条件下使用时，软件产品维持规定的性能级别的能力。成熟性：是指软件产品避免因软件中错误发生而导致失效的能力。容错性：是指在软件发生故障或违反指定接口的情况下，软件产品维持规定的性能级别的能力。易恢复性：是指在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力。可靠性依从性：是指软件产品依附与同可靠性相关的标准、约定或法规以及类似规定的能力。三、易用性：是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。易理解性：是指软件产品使用户能理解软件产品是否合适以及如何能将软件用于特定的任务和使用环境的能力。易学性：是指软件产品使用户能学习它的能力。易操作性：是指软件产品使用户能操作和控制它的能力。吸引性：是指软件产品吸引用户的能力。易用性依从性：是指软件产品依附与同易用性相关的标准、约定、风格指南或法规以及类似规定的能力。四、效率：是指在规定条件下，相对于所用资源的数量，软件产品可提供适当的性能的能力。时间特性：是指在规定条件下，软件产品执行其功能时，提供适当的响应时间和处理时间以及吞吐率的能力。资源利用性：是指在规定条件下，软件产品执行其功能时，提供合适的数量和类型的资源的能力。效率依从性：是指软件产品依附与同效率相关的标准或约定的能力。五、维护性：是指软件产品可被修改的能力，修改可能包括修正，改进或软件适应环境、需求和功能规格说明中的变化。易分析性：是指软件产品诊断软件中的缺陷或失效原因，以及判定待修改的部分的能力。易改变性：是指软件产品使指定的修改可以被实现的能力。稳定性：是指软件产品避免由于软件修改而造成意外结果的能力。易测试性：是指软件产品使已修改软件能被确认的能力。维护性依从性：是指软件产品依附与同维护性相关的标准或约定的能力。六、可移植性：是指软件产品从一种环境迁移到另一种环境的能力。适应性：是指软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段，就可能适应不同的指定环境的能力。易安装性：是指软件产品在指定环境中被安装的能力。共存性：是指软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力。易替换性：是指软件产品在环境相同、目的相同的情况下替代另一个指定软件产品的能力。可移植性依从性：是指软件产品依附与同可移植性相关的标准或约定的能力。
由此看来每一个阶段的质量都起着决定性的作用。 以上提及的四个阶段的质量将引出以下几个软件质量保证的关键要素。 完备的需求分析 需求分析的目的是让项目组明白要做什么，是决定所开发出来的软件应当是“长什么样的”，显然完备的需求分析是高质量软件的前提。如果所开发出来的软件与用户所希望的并不一致，那不可能让用户说“这个软件的质量很好” 。如果方向不对，软件开发得再“好”也没有意义。需求分析失误所带来的开发成本是高昂的，这一点在《软件工程》这类书籍中都会提及，因此，整个行业对于需求分析的重要性都具有足够的认识。当然，知道其重要性与如何获得完备的需求分析又是两回事，至于如何做好需求分析请读者参考相关书籍。 需求分析如果出现失误的话有一个特点—— 它一定会暴露！只不过存在是暴露在软件开发过程中还是在用户手中之别。因此，需求分析所造成的问题尽管严重，但它能被发现进而能得到项目组的重视，从而也一定能被修复，只是不同阶段发现这类问题所花费的成本将有所不同。 设计 设计阶段是通过设计方法找出软件实现更好的方法，注意这里是“更好”两个字，而不是强调最好。 不良设计并不会象需求分析失误那样很容易暴露出其本质，相反，它所暴露出的更多是表象，比如逻辑复杂、维护时举步为艰等等。如果参与者不具备一定的洞察力以发现隐藏在现象背后的不良设计本质，则很有可能身受其害却不能自拔，还以为“本来就有那么复杂”。 项目的开发是一个逐步演进的过程，项目组成员对于需求的理解也是逐步加深的，一开始合适的设计到后面看来很有可能就不够全面或显得力不从心，如果仍沿用以前的设计则自然将暴露出它的不足，进而会出现需要更高的维护成本。重构思想的提出，就是用于帮助项目演进设计的，当然，在运用重构方法时，应尽可能保证项目有足够的单元测试用例，以预防重构时又引入新的缺陷。重构不只是一个词，其核心应当是一个方法论，一个用于优化设计的方法论。 编程好习惯 设计阶段输出的结果就是蓝图，但好的蓝图并不能保证最后的质量一定就好。拿造房子打个比方，图纸设计得再好，如果建造时用的材料不过关，那最终的房子一定好不了。那软件开发中的“建筑材料”又是什么呢？就是程序员所编写的代码。如何保证其质量呢？这需要通过良好的编程习惯去保证。 在现实的项目中，设计有可能与编码会有一定的揉合，即通过进行一定的编码来辅助设计。这种实践方式并不影响这里将设计与编码分为两个质量保证关键要素。 验证 验证很容易让人想到质量保证的常用方法之一，即测试。但验证应当包含更多的内涵，比如求证软件需求是用户所希望的就是其中的一种。 对于验证的理解仍需要拿房屋的建造作为一个比方，以便加深理解。在房屋的建造过程中，当建筑材料到了工地以后，需要对其进行检验，以保证它的质量是合格的，否则不能用于建造。对应于软件开发，这个阶段就是单元测试。当软件工程师编写了代码以后如何保证代码的行为是其所希望的呢？那只能通过单元测试去验证。房子建造好了以后，还得对房子进行整体的验收以确保其最终是合格的。比如抽查墙壁所使用的水泥与沙的配比是合适的。虽然水泥和沙在进入工地时都经过了质检且是合格的，但在建造的过程中需要按一定的比例混合它们以作建筑粘合剂，而混合比例将确定粘合强度。在软件开发过程中，软件集成测试就如同房子在建造好了以后的验收。 从上面的比方能得出几个结论。第一，在软件开发过程中单元测试是必不可少的。它的缺少如同将没有检验过的建筑材料用于建造一样。第二，单元测试应当在集成测试之前完成。有的项目在一开始时并没有单元测试流程，但后来发现需要增加这个环节，于是出现了集成测试完成了以后，再进行单元测试这种情形。这种情形还是有点怪怪的，这如同房子已造好了，再将墙打掉去检查里面的砖是否是好的一样。“将墙打掉检查砖”这种行为的勇气虽然可佳，但是如果尽早地在项目中部署单元测试就能避免这种怪现象的发生。 集成（包括开发集成和系统集成）测试在软件行业被广泛采用以保证软件质量，但单元测试对于软件质量保证的重要性在整个行业还缺乏广泛的、深刻的认识，其更多地被当作是负担而不是一种有效的质量保证手段。
