软件质量透视

第11章软件质量透视通过对前面的学习，我们对传统的软件测试有了一个比较全面的认识。我们认识到测试人员需要对产品的质量负责。那么什么是质量，该如何看待质量？本章重点讨论：什么是质量？如何才能提高软件产品的质量？

Deming的14条质量原则是什么？

CMM、PSP和TSP之间的关系是什么？11.1质量的定义

ISO关于质量的定义表示如下：“一个实体（产品和服务）的所有特性，基于这些特性可以满足明显的或隐含的需要。”我们可以引申出质量的3个维度：符合目标目标是客户提出的，符合目标就是判断我们是不是在做我们需要做的事情。在这个维度上用户认为的质量是“产品是否按照用户的需要运行”11.1质量的定义符合需求检验产品是否在做让它做的事情。软件产品的需求必须是可度量的，并且产品的需求要么被满足，要么不被满足。根据这种度量，质量也应该是二维的状态，也就是说产品要么是有质量，要么是无质量的。对于开发者而言，他们认为质量就是满足用户的需求或规格说明书。在此满足规格说明书成为了产品本身的一个终点。11.1质量的定义符合实际需求。实际的需求包括用户明确说明的和隐含的需求。而往往我们会忽略隐含的需求。因此控制一个产品的质量的过程中必须关注这些隐含的需求，并给予应有的验证。产品是为用户提供服务的，凡是不满足客户需求的，我们都认为是一个失效的产品。所以我们的产品必须围绕着客户的需求进行开发和验证。11.1质量的定义“客户”和“用户”的区别：客户之真正能够决定是否购买你软件的人，而用户是实际使用软件的人。我们开发软件是应该更多地站在用户的角度去开发，要做到让用户用得方便、舒服、提高了效率。用户的意见能直接反馈到客户那里，作为客户选购软件的依据。

了解两者的区别，在分析需求和进行产品的质量验证时可以做出不同的权衡。11.1质量的定义当每个人提到质量时，经常会遇到下列矛盾，在这些矛盾中隐含着对质量的承诺：质量需要一个承诺，尤其是高层管理者的承诺。为了得到更高的质量，高层管理者必须和员工进行紧密的合作。许多相信没有缺陷的产品和服务是不可能的。但是控制在一定级别的缺陷数量是正常的，是可以接受的。11.1质量的定义质量经常是和成本紧密联系在一起的，一个高质量的产品同时也意味着高投入。这是设计的质量和一致性质量的一个矛盾。一个高的质量要求需求规格说明书足够详细，并根据这些规格说明书可进行定量的分析。然而许多组织没有能力或者不愿意制作如此详细的规格说明书。技术人员经常相信规范和标准会束缚他们的创造力，因而不愿意遵照标准做事。然而如果要得到高质量的产品，就必须遵循良好定义的标准和过程。11.2质量的预防和检测

质量管理可以降低产品的成本，这是因为缺陷发现和修改得越早，所花费的成本就越少。尽管在初期时，其成本投入相当大，但是从长远来看，质量管理将减少后期的维护费用，并最终得到一个高质量的产品。研究表明：维护阶段发现和修改一个缺陷的成本时需求阶段的70倍甚至更高。一个有效的质量管理成本包括4个部分：预防成本、检视成本、内部缺陷发现和修改成本、外部缺陷发现和修改成本。11.2质量的预防和检测预防成本包括防止缺陷最初产生的活动的成本。检视成本包括测量、评价和审计一个产品或服务是否和标准与规格相一致而花费的成本。内部缺陷发现和修改成本是那些在产品交付之前发现和修改错误所投入的成本。

11.2质量的预防和检测外部缺陷发现和修改成本是产品发布之后发现和修改缺陷所花费的成本。外部缺陷有可能是灾难性的，因为它们可能会损害企业的名誉并最终导致销售的下滑。预防的最大回报是在增加预防成本的同时减少外部缺陷，进而提高产品质量，减少维护成本和产品成本。11.3如何提高软件产品的质量如何提高软件的质量已经不是一个纯粹的技术问题，而是一个工程问题。自从软件危机产生以来，出现了很多关于提高产品质量方面的理论和方法：有从技术角度出发的，如面向对象的技术的产生和推广；有从自动化角度出发的，如CASE工具、过程控制软件、自动化管理平台等；有从过程模型角度出发，如:迭代模型、螺旋模型等；11.3如何提高软件产品的质量有从管理角度出发的，如：团对管理、责效管理等；有从测试角度出发的，如:把Deming的PDCA循环应用到全流程的测试过程上来；一些相应的规范和标准也孕育而生，例如：ISO9000系列，CMM等。然而每一种技术都不是绝对的，软件质量的提高应该是一个综合的因素，需要从各个方面进行改进，同时还需要兼顾成本和进度。

11.3.1流程对质量的控制从一个软件企业的长远发展来看，如果要提高产品的质量首先应当从流程抓起，规范软件产品的开发过程。这是一个软件企业从小作坊的生产方式向集成化规范化的大公司迈进的必经之路，也是从根本上解决质量问题，提高工作效率的一个关键手段。11.3.1流程对质量的控制

软件产品的开发同其他产品（如汽车）的生产有着共同特性，即需要按一定的过程来进行生产。

在工业界，流水线生产方式被证明是一种高效的，且能够比较稳定地保证产品质量的一种方式。通过这种方式，不同的人员被安排在流程的不同位置，最终为着一个目标共同努力，这样可以防止人员时间的内耗，极大地提高了工作效率。并且由于其过程来源于成功的案例，因此其最终的产品质量能够满足过程所设定的范围。11.3.1流程对质量的控制

软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中，这就形成了软件工程过程，简称开发流程。开发流程告诉我们该怎样一步一步实现产品，可能会有那些风险，如何避免风险等。由于流程源于成功的经验，因此，按照流程进行开发可以使我们少走弯路，并有效地提高产品质量，提高用户的满意度。11.3.1流程对质量的控制

目前流行的流程方法有很多种，不同的流程适合不同类型的项目。瀑布模型该模型是应用最为广泛的一种模型，也是最容易理解和掌握的模型，但是它的缺陷也是显而易见的。遗留的需求或者不断变化的需求会使得该模型无所适从。然而，对于那些容易理解但很复杂的项目，采用瀑布模型比较适合，因为可以按部就班地去处理复杂的问题。在质量要求高于成本和进度时，该模型表现突出。11.3.1流程对质量的控制螺旋模型是一个经典的模型，它关注于发现和降低项目的风险。螺旋型项目从小的规模开始，探测风险，制定风险控制计划，接着确定下一步项目是否还要继续，然后进行下一步螺旋的反复。该模型的最大优点是随着成本的增加，风险程度随之降低。缺点是比较复杂，且需要管理人员有责任心，专注以及有管理经验。对管理人员的经验和素质依赖比较大。11.3.1流程对质量的控制

RUP模型该模型是Rational公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程架构。

RUP为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。11.3.1流程对质量的控制

RUP有两个轴，一个轴是时间，这是动态的；另一个轴是工作流轴，这是静态的。在时间轴上，RUP分为4个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上，RUP设计了6个核心工作流程和3个核心支撑工作流。核心工作流轴包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括：环境工作流、项目管理工作流和配置与变更管理工作流。RUP流程示意图11.3.1流程对质量的控制

IPD模型流程是由IBM提出的一套集成产品开发流程，非常适合于复杂的大型开发项目，尤其涉及到软硬件结合的项目。

IPD从整个产品角度出发，流程综合考虑了从系统工程、研发（硬件、软件、结构工业设计、测试、资料开发等）、制造、财务到市场、采购、技术支援等所有流程，是一个端到端的流程。11.3.1流程对质量的控制在IPD流过程中总共划分了6个阶段（概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段），4个决策评审点（概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点）以及6个技术评审点。IPD流程示意图11.3.1流程对质量的控制

IPD流程是一个阶段性模型，具有瀑布模型的影子。该模型通过使用全面而且复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。一定程度上，该模型是通过流程成本来提高整个产品的质量并获得市场的占有。由于该模型没有定义如何进行流程回退的机制，因此对于需求经常变动的项目，该流程就显得不太适合了。并且对于一些小项目，也不是非常适合使用该模型。11.3.2流程与技术流程和成功不是等价的。没有流程，成功就不可能得到保证，但是有了流程并不意味着肯定能够成功。技术是成功的另外一个必要条件。11.3.2流程与技术对于软件开发者来说，要保证软件的质量，需要掌握多方面的技术，包括分析技术，设计技术，编码技术和测试技术等。在国内有一个普遍的非正常现象，就是大家觉得只有编程才是玩计算机的真正技能。就好像造一套房子，其他都不重要，只要砖瓦匠有高超的技能就行了。我们缺少系统级的工程师，在分析和设计方面的工作做得很不扎实。11.3.2流程与技术需求是一个项目的灵魂。模棱两可的需求不可避免的后果就是返工——重做一些你认为已做好的事情。返工会耗费总开发费用的40％，而70％～85％的重做是由于需求方面的错误所导致的。11.3.2流程与技术设计是最能体现一个工程师能力的地方。一个好的设计基本上决定了产品的最终质量。设计是把需求转换成系统的一个关键步骤，它需要从自然语言描述的需求中寻找出设计的基础单元，构建出整个系统的构架。在RUP模型中关于系统架构师和设计师的定位是相当高的。关于设计方面的技能是很广的，包括从系统的结构化设计到面向对象设计。设计人员需要掌握一定的建模技术。11.3.2流程与技术

UML是国际上比较流行的一种建模语言，在嵌入式方面SDL也是一种很好的建模工具。

《设计模式》是一本在设计思想方面总结得非常出色得书，作为一个设计人员，必须好好研究一下。11.3.2流程与技术现在的程序员热衷于掌握多种编程语言，或者过分讲究语言的技巧化，而往往忽略了编程语言的规范化。不规范的语言应用给程序的可理解性、可维护性以及可测试性带来很大的不便，甚至会损害产品的质量。11.3.2流程与技术如果大家是在做研究性的项目和纯粹兴趣性的项目，那么大家充分发挥自己的编程天才是可以的。但是对于一个公司，其产品最终是要交给用户的，需要遵循的是一个软件产品的开发过程。因此这类软件的开发需要遵循一定的编程规范，毕竟开发的软件不是自己用的，还需要和别人集成，还需要给以后版本重用和维护。总之，流程很关键，技术也很重要，“鱼”和“熊掌”，两者都不能放。11.3.3全面质量管理作为全面质量管理的最初倡导者和成功者Deming，其质量理论包括统计理论的使用。统计有助于我们特别关注于问题的主要因素，当问题改正后能极大地提高产品的质量。11.3.3全面质量管理1.Deming的质量原则：第一个原则：要有一个坚定不移的目标为了应用该原则，一个质量保证组织可以：开发一个质量保证计划，提供一个长期的质量方向；需要软件测试者为每个项目开发并维护一个一致的测试计划。鼓励质量分析人员和测试人员遵循具有革新的方法来最大化产品的质量。致力于不断改进质量过程。11.3.3全面质量管理第二个原则：吸收新的哲学质量必须成为一个新的信仰。根据Deming的理论：“生存的成本和需要花钱购买的商品和服务是成反比的，如：可靠的服务可以降低成本，延迟和错误却会提高成本。”由于延迟和错误，商品和服务的消费被终止了，这降低了它们存在的标准。在系统中，对可接受的层次和缺陷忍耐程度是质量和产量之间的一个路障。11.3.3全面质量管理为了应用该原则，一个质量保证组可以：提高关于质量的价值和需要；提高质量保证部门的地位，是他们和别的部门同样重要；纠正对质量部门是“看门狗”的消极看法。11.3.3全面质量管理第三个原则：不要依赖海量检查传统的想法认为检查可以排除糟糕的质量。当难于确定在过程中一个缺陷在哪边产生时，一个好的方法是通过检查关注于我们做的如何、而不应针对最终的产品。质量应当时内在的，而不是通过无数的检查获得的。为了做到该原则，一个质量保证组织可以：在整个开发生命周期中，提高并使用技术评审、走读和检视来获取质量；在整个组织中灌输质量意识，并把它作为一个切实的、可度量的工作产品；需要信息技术质量的统计证明。11.3.3全面质量管理第四个原则：结束基于纯粹价格标签裁定的商业实践“两个或多个以上的同种商品的供应商会成倍地加剧损害，这些损害是内在必然的，并且对任何一个供应商都是不利的。”为了更好地服务于公司，购买方可以通过和供应商建立一种长期的忠实的关系，并且与一个专门的供应商建立信任关系。为了应用该原则，一个质量保证组织可以：需要软件质量和测试提供者提供能够证明他们质量的统计数据。对每一个质量保证工具、测试工具和服务选择一个最好的供应商，并且建立一个与质量计划一致的工作关系。11.3.3全面质量管理第五个原则：产品和服务系统稳定地、长期地提高改进不是一时的努力——管理层有责任不断地提高质量。具体可以：不断地提高质量保证和测试过程。不要依赖于主观的判断。使用统计技术，如测试分析和通过主因及效果分析揭示问题根源等方法。11.3.3全面质量管理第六个原则：建立培训和再培训制度在很多公司，很少甚至没有培训，工人们不知道何时才能正确地完成他们的任务。Deming强调：只要工作成果无法受到统计控制，并且还能获得更大的好处时，培训就不应当被终止。为了应用该原则，可以:建立现代的培训辅