读书笔记 -《代码大全》第20章软件质量概述

这一章主要给我们讲了什么是软件质量，它有哪些特性，如何保障软件质量，也就是有哪些活动、技术可以保障软件质量，以及何时采用什么样的方法、技术来保障软件质量，我们怎样组合这些技术才能达到最大效能等问题。

整章的描述都围绕着这样的问题，甚至整本代码大全其实都是在寻求这些问题的解答。但本书阐述的大多是从过往经验中抽象出来的问题，比较理想化。书中并没有讲到如何把学到的知识应用于实际情况中。而实际情况无疑是复杂的，因人而异的，甚至是难以协调的，那么除了要把这章知识学透，还应该更多思考我们在日常事务中如何很好地运用这些知识，以创造出它应有的价值。

---

软件质量的特性

软件质量，顾名思义，指整个软件系统的质量。面对日益复杂的软件系统，我们描述它的质量已经不能用简单的几句话下定义了，应该要从不同方面来衡量、定位，那么这不同方面或说指标都有哪些呢？
本章从外在和内在两个层级来描述软件质量特性，而它们内部又分为很多种具体的特性，从不同的角度阐明了软件质量的方方面面，也让我们可以从不同角度去观察并且从不同角度设立不同的质量目标。

• 外在特性（用户关心的）

• 正确性
• 可用性
• 效率
• 可靠性
• 完整性
• 适应性
• 精确性
• 健壮性

• 内在特性（程序员应该关心的）

• 可维护性
• 灵活性
• 可移植性
• 可重用性
• 可读性
• 可测试性
• 可理解性

后续的质量保障工作其实就是围绕这些质量目标来进行的。所以在执行质量保障工作之前，首先是目标先行，有了目标，做事才能有的放矢，效率才高。
但是因为这些质量特性之间有相生也有相克的，再加上现实情况的复杂，而且投入的资源和成本的有限。那么我们不可能完成所有这些质量目标的。所以回到了一个权衡的过程，而往往最难的一步就是根据实际情况做出权衡。

---

改善软件质量的技术

找出了质量目标，接下来就是订立质量保障计划。
实施质量保障计划需要引入一些有效的质量保障活动（技术）。这些技术都有哪些呢？

• 设立明确质量目标
• 明确定义质量保障工作（让员工知道质量应当放在第一位）
• 测试策略
• 软件工程指南（问题定义、需求分析、架构设计、构建以及系统测试）？？
• 非正式技术复查（code review，互相走读，结对审查）
• 正式技术复查（会议评审代码？或专门的工具过代码？）
• 外部审查
• 开发过程

• 对变更进行控制的过程
• 结果的量化（参见《Principles of software Engineering》有关度量质量特性的详细内容）
• 制作原型

• 等等

---

不同质量保障技术的相对效能

根据过去的统计，不同质量保障技术，效能是不一样的。下面我们从以下几个方面来衡量它们的“效能”：

• 缺陷检测率
• 找出缺陷的成本
• 修正缺陷的成本

缺陷检测率的对比：（一张图足以说明问题）

各软件检错措施缺陷检测率.png

所以单独使用一种技术，最好的检出率也才65%，达不到很好保障软件质量。所以需要综合运用各种技术，向更高的缺陷检测率发起冲击。
书中介绍了极限编程的平均缺陷排除率为90%，最好的情况可达到97%，是一个值得推荐的开发方法，它运用了如下这些保障技术组合：

极限编程缺陷检测率.png

很多人将这一效率归功于极限编程实践中的协作，即结对编程。

找出缺陷的成本
查找缺陷的成本受到诸多因素影响，举几个例子：

• 特定的检测技术所能找到的缺陷总量
• 缺陷被发现时所处的开发阶段
• 经济因素之外的其他因素

大部分研究（具体指哪里的研究？是否真的靠谱？这是值得考究的问题）都发现，检查比测试的成本更小。阅读代码每小时能够检测出的缺陷要比测试高出80%左右（Basili and Selby 1987）（1987年的数据是否还适用于现在？）。后来，IBM的一项研究（样本量多大？具体什么样的研究？使用了什么方法做研究？）又发现，检查（手工阅读代码？）发现一个错误只需要3.5个工作时，而测试则需要花费15~25个工作时（Kaplan 1995）。

修正缺陷的成本
一个缺陷存在的时间越长，消除它的代价就越高昂。因此能够尽早发现错误的检测方法可以降低修正缺陷的成本。
这里又要拿检查和测试做对比了，首先如代码检查，一举可以确定问题的现象和原因；而测试，则只能发现问题表象，而要找到并从根本上修正缺陷还需要额外的工作。

微软应用部门发现：代码复查（review）投资回报率达到1.38，而测试只有0.17。

推荐的联合技术：

• 对所有的需求、架构以及系统关键部分的设计进行正式检查
• 建模或者创建原型
• 代码阅读或者检查
• 执行测试

---

什么时候进行质量保证工作

尽早捕捉错误才能有效地节省成本。

• 需求中一个缺陷会孕育出设计上的一个或多个缺陷，而这些设计错误优惠繁殖出更多的代码缺陷。
• 需求中一个错误会导致多余的架构设计或错误的架构决策。多余的架构设计又导致多余的代码、测试用例和文档。
• 一个需求上的错误可能产生最终不得不被抛弃的架构、代码以及测试用例。

在早期就开始强调质量保证工作，贯彻整个项目，在开工时添加到项目计划中，并应该作为项目的结束点，当整个工作结束的时候检验产品的质量。

---

软件质量的普遍原理

软件质量的普遍原理就是改善质量以降低开发成本。

提高生产效率和改善质量的最佳途径是减少花在这种代码返工上的时间，无论返工的代码是由需求、设计改变还是调试引起的。
前期充足准备，只要避免引入错误，就可以减少调试时间，从而提高生产力。因此，效果最明显的缩短开发周期的办法就是改善产品的质量，由此减少花费在调试和软件返工上面的时间总量。
而且，NASA软件工程实验室在分析400人年工作量的50个开发项目的300万行代码后发现，更多的质量保证工作能降低错误率，但不会增加开发总成本（Card 1987）。

质量保证计划核对表.png

---

更多资源（书籍）

• Ginac, Frank P. 《Customer Oriented Software Quality Assurance》（《面向用户的软件质量保证》） 。这是一本言简意赅的书，其中描述了质量特性、规律、质量保证计划、测试在质量保证中的角色以及著名的质量改善计划。
• Lewis, Wiilliam E.《Software Testing and Continuous Quality Improvement》（《软件测试和连续质量改进》）。这本书广泛讨论了质量生命周期，包括有关测试技术的深入讨论，它还提供了大量的表格和核对表。