前言
故事发生在2001年初，周一早晨，新上任的质量保证部经理召集部门的全体人员开会。当时该部门有8个测试人员和5个文档、3个美工。对于一个刚刚成立的拥有员工70多人的软件公司来说，该部门人员占比达23%之多，其投入的规模和同行小公司相比不算小。与会过程中，就软件质量问题，大家各抒己见。
经理说：“公司自从转向软件开发以来，开发工作开展很顺利，我们质量保证部主要工作是测试，尽快、尽多、尽早地发现程序中的错误，保证开发出来的产品质量，其责任重大。”
测试工程师甲说：“缺陷就是Bug，程序员开发完产品后，咱们测试人员尽可能多地发现其中的Bug，遗留在产品中的Bug就会越少，产品质量就会越高。”
测试工程师乙说：“只要我们发现了所有的Bug，让程序员改正过来，我们就可以放心地对用户说，我测过的软件你放心，绝对不会再有质量问题。”
…….
会议在经理的主持与分配任务中告一段落。
上述对软件产品和软件产品质量的说法，从事软件研发的人可能都听到过。相隔7年之后，回首往事，仔细思考一下，其中类似说法有多少是完全正确的呢？软件质量真的像他们说的那样吗？
在20世纪90年代中期，几次著名的分析都得到了相同的具有普遍性的结论，即软件项目的成功率非常低。著名的观点如，软件开发仍然具有高度的不可预知性，只有大约10%的软件项目在最初估计的预算和进度内成功地交付；与其说管理规范是技术进步，还不如说是成功和失败的鉴别器；软件废品和返工的程度是不成熟过程的象征。
目前，随着软件工程技术的不断发展，人们已经逐渐认识到，软件质量是多方面的活动协力构建起来的，由软件开发整个过程的质量所决定，质量问题不是仅仅通过测试就能发现并解决的。大量实践证明，软件产品与传统产品有着不同的特征，如不可见性、灵活性、复杂性等，所以软件缺陷的预防自始至终是重要的，广义的软件开发质量保证活动，更多地强调软件缺陷的预防、及时发现与剔除。
因此，不像建筑工程那样精确地衡量、计算出每一元钱在软件产品中是如何花费的，软件开发过程的控制和软件质量也要远比其他工程制品的管理复杂得多。
那么，什么是“软件产品质量”呢？
Crosby将质量定义为“符合需求”，而Juran认为是“适于使用”。质量的这两个定义相互关联，已经被人们广泛采纳和使用。
“符合需求”隐含着需求必须明确陈述出来，使之不被误解。在开发和生产过程中，不断进行度量以确定对这些需求的符合性。不符合需求就被视为缺陷。
“适于使用”更多地考虑了客户需求和预期的作用。由于不同的客户会以不同的方式使用产品，产品必须具有适合使用的多种要素，这些要素的每一个都包含有质量特性（适于使用的参数）。最重要的两个质量特性参数就是设计质量和符合性质量。
由于生产者坚持将“符合需求”以及将客户满意度作为质量的最终验证标准，质量的定义实际上分成了两级：狭义的质量（“小q”），即内在产品质量，包括了缺陷率和可靠性；广义的质量（“大Q”），则包括了产品质量、过程质量和客户满意度。
总之，软件产品质量一般都指利用适当的资源为用户提供能满足要求的产品，达到用户满意。软件质量评价要素主要包括：① 功能性；② 可靠性；③ 易用性；④ 效率；⑤ 维护性；⑥ 可移植性；⑦ 正确性；⑧ 健壮性；⑨ 完整性；⑩ 安全性；⑪ 可用性；⑫ 可理解性；⑬ 可测试性；⑭ 可再用性等。
软件质量始于开发人员本身，如果任何程序模块都存在大量缺陷的话，就很难去测试且需要花很多时间才可能集成到较大的系统中，甚至还会给用户带来很多麻烦。不良质量也会导致进度问题，有缺陷的产品交付期会较长。经过测算，大多数的软件专业人员在开发和最终测试期间，花费近一半的时间来测试并修复他们的产品。
当写一些小程序时，大多数人都会有很高的生产率；而一旦开发较大的程序时，生产率会急剧下降。虽然开发较大的系统还涉及一些额外的架构和设计工作，但大多数增加的工作量还是由缺陷引起的。随着程序的增大，平均花费在发现和修复每个缺陷上的时间会以指数级增加。然而，如果我们能够自始至终地编写高质量的模块化程序，就会生产出更好的产品并且提高生产率和组织效率。
因此，为了保证软件产品质量，需要进行以下一系列的工作。
（1）定义质量需求，明确本产品的质量目标。要明确影响本产品质量的缺陷可能有哪些，如何避免。
（2）定义质量管理过程，采用软件工程的方法管理开发过程，可通过审查/评审/测试/验证等手段来贯彻落实“早预防、早检查、早控制”的保证质量策略。
（3）建立一个能尽早面对风险的迭代式的生命周期过程。
（4）定义每个过程成果的质量要求/质量标准，加强软件的测试。
（5）签订合同，确定客户方相关负责人、责任以及权利，并加强和客户的沟通，了解客户真实的要求和潜在需求。
（6）将过程建立在构架优先方法的基础上，同时设计方法要转向基于构件的开发。
（7）编码过程中，要让员工以最佳的状态投入到工作中，最好不要加班。这是因为员工状态不佳时，编写的代码低级错误较多，虽然不致命，但浪费很多测试和调试的时间，所以加班得不偿失。
（8）测试时要由有经验的高级程序员对业务逻辑部分进行白盒测试。
（9）建立一个经济上具有伸缩性的可配置的过程，做好需求管理、配置管理及变更管理工作。
（10）建立一个规范的软件工程过程，包括有效的缺陷管理、全面的计划和及时、准确的项目跟踪及报告。
本书主要内容
全书共分为四个部分：
第一部分——包括缺陷综述、需求开发与管理、配置与变更管理3 章。介绍了什么是缺陷，着重阐述了影响软件质量、造成缺陷的各种因素。
第二部分——包括同行评审、软件测试、QA发现的不符合问题的处理3章。描述了发现和清除缺陷的7种手段中最有效的3种手段。
第三部分——包括软件度量和缺陷管理2 章。阐述了缺陷的度量、分析、控制以及预防，给出了具体操作的例子。
第四部分——包括经验教训库、思考和附录。
本书的总体逻辑体现在下图中，通过缺陷预防、缺陷发现、缺陷管理和数据度量4个大的方面进行论述，其中的虚线部分是本书中没有描述的内容。
软件质量保证范围
本书将从软件缺陷的产生、预防、清除、管理等方面，理论结合实践地进行阐述，希望能给大家在软件开发和管理上提供借鉴。
本书内容是相关理论与实践的结晶，是我们利用业余时间总结CMMI过程改进中方法与经验基础上编写的，也是真实项目与产品研发过程实施的一些心得。当然，书中的内容远不止于此，适度增加了对相关经验的升华与前瞻，大大提高了知识性、丰富性、实用性、可读性。
本书编者
本书编写过程中分工如下：
于波、姜艳负责总体构架和篇章的布局设计、主编，最终统筹编写完成。于波、姜艳、王西京、宋莉莉、田广志等几人共同编写、校对。其中，第1 章“缺陷综述”、第4章“同行评审”以及附录由姜艳、于阔完成；第2章“需求开发与管理”、第3章“配置与变更管理”、第7章“软件度量”、第8章“缺陷管理”、第10章“思考”（10.3节除外）由于波完成；第5章“测试”、第10章10.3节由王西京完成；第6章“QA发现的不符合问题的处理”由宋莉莉完成；第9章“经验教训库”由于波、姜艳、王西京、于阔、宋莉莉、田广志共同完成。书中所有图表的绘制工作由于波、姜艳、王西京、宋莉莉、张娜完成。
致谢
对本书相关章节有贡献的还有任广新、姜雨、刘伟、田晓菲、任飞等同志，他们给了很多合理化建议与无私的帮助和支持，一并在此说明并衷心表示感谢。
感谢参与本书编写的相关人员，你们的细心和无私帮助让我心生暖意，你们对学术的热忱也是督促我不断反思、提高的动力。在我奋战的时候陪我每一天，给了我很多的启发和建议，也给了我很多信心。同时，我们团队的努力时刻都在提醒和激励我。让我们不断地总结经验，将集体的智慧跃然纸上，让更多的读者受益。
特别感谢国际软件工程权威、北京航空航天大学教授、SEI主任评估师、北京航空航天大学软件工程研究所创始人、赛柏科技的CTO周伯生教授阅读了本书初稿，并对修改提出了专家性的意见，感谢伯生教授严谨的治学态度和渊博的理论、实践知识。
在本书涉及的内容中，我们研究、学习和借鉴了网络资料、相关博客以及很多专业书籍，特别是周伯生教授及其带领的团队提供的资料，因此，编写过程中仍然会有部分内容借鉴了同行们的思想，可能在本书中没有明确标明来源及不知您的相关声明，冒犯了您的版权，表示歉意，同时请直接与我们联系，谢谢。