软件质量管理

1、第第 9 章章 软件质量管理软件质量管理.2 9.1 软件的质量属性和质量要素软件的质量属性和质量要素.2 9.2 商业目标决定质量目标商业目标决定质量目标.3 9.3 质量保证能够保证质量吗质量保证能够保证质量吗.4 9.4 质量人员的状况质量人员的状况.6 9.4.1 郁闷的质量人员.6 9.4.2 路在何方.7 9.4.3 赞美诗.8 9.5 全面软件质量管理全面软件质量管理.9 9.5.1 模型.9 9.5.2 质量人员的职责.10 9.5.3 制定质量计划.11 9.5.4 技术评审.13 9.5.5 软件测试.16 9.5.6 过程检查.16 9.5.7 缺陷跟踪工具.17 9.6

2、 小结小结.19 第第 9 章章 软件质量管理软件质量管理 软件质量管理是充满争论的话题。被人们奉为软件质量管理圣经的 CMM 和 ISO9001 似 乎并不奏效，现实和理想之间的差距太大。 本章树立一个重要的理念：商业目标决定质量目标。提高软件质量的最终目的是为了赢 利，而不是创造完美无缺的产品。因此对于普通商业软件而言，并不是“质量越高越好” ， 而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。 经典软件工程教科书以及 CMM 和 ISO9001 总是抛开商业目标谈质量管理，本末倒置， 纸上谈兵，误导了大量读者，所以质量管理才变得那么艰辛。本章给出了一套实用主义的 “全面

3、软件质量管理”方法。 质量人员在全面软件质量管理中发挥重要作用，本章探讨了质量人员的工作状况，给他 们一些声援，并提出了改善工作状况的建议。 9.1 软件的质量属性和质量要素软件的质量属性和质量要素 在讲述软件质量管理方法之前，我们首先要搞清楚什么是软件质量。 词典对质量的定义是： 典型的或本质的特征； 事物固有的或区别于其他事物的特 征或本质； 优良或出色的程度。 CMM 对质量的定义是： 一个系统、组件或过程符合特定需求的程度； 一个系统、 组件或过程符合客户或用户的要求或期望的程度。 上述定义很抽象，人们看了准会一脸迷惘。就让我们用“人的健康”来类比解释软件质 量吧。 古时候人们以为长得

4、结实、饭量大就是健康，这显然是不科学的。现代人总是通过考察 多方面的生理因素来判断是否健康，如测量身高、体重、心跳、血压、血液、体温等。如果 上述因素都合格，那么表明这人是健康的。如果某个因素不合格，则表明此人在某个方面不 健康，医生会对症下药。 通过类比，我们这样理解软件质量： 软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们 通过改善软件的各种质量属性，从而提高软件的整体质量（否则无从下手）通过改善软件的各种质量属性，从而提高软件的整体质量（否则无从下手） 。 软件的质量属性很多，如正确

5、性、精确性，健壮性、可靠性、容错性、性能、易用性、 安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等。表 9- 1 是常见质量属性的描述，先让读者对软件质量属性有个初步的了解。 质量属性描述 正确性正确性是指软件按照需求正确执行任务的能力。 “正确性”的语义涵盖了“精确性” 。 正确性无疑是第一重要的软件质量属性。 健壮性健壮性是指在异常情况下，软件能够正常运行的能力。正确性与健壮性的区别是： 前者描述软件在需求范围之内的行为，而后者描述软件在需求范围之外的行为。健 壮性有两层含义：一是容错能力，二是恢复能力。 可靠性可靠性是一个与时间相关的属性，指的是在一定环境下，

6、在一定的时间段内，程序 不出现故障的概率，因此是一个统计量，通常用平均无故障时间来衡量。软件可靠 性问题通常是由于设计中没有料到的异常和测试中没有暴露的代码缺陷引起的。 性能性能通常是指软件的“时间空间”效率，而不仅是指软件的运行速度。人们总希 望软件的运行速度高些，并且占用资源少些。 易用性易用性是指用户使用软件的容易程度。软件的易用性要让用户来评价。 清晰性清晰意味着工作成果易读、易理解，开发人员只有在自己思路清晰的时候才可能写 出让别人易读、易理解的程序和文档。 安全性安全性是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。一般地， 如果黑客为非法入侵花费的代价（考虑时间、费用

7、、风险等因素）高于得到的好处， 那么这样的系统就可以认为是安全的。 可扩展性可扩展性反映了软件适应“变化”的能力。在软件开发过程中， “变化”是司空见惯 的事情，如需求、设计的变化，算法的改进、程序的变化等。可扩展性是系统设计 阶段重点考虑的质量属性。 兼容性兼容性是指两个或两个以上的软件相互交换信息的能力。兼容性的商业规则是：弱 者设法与强者兼容，否则无容身之地；强者应当避免被兼容，否则市场将被瓜分。 可移植性软件的可移植性指的是软件不经修改或稍加修改就可以运行于不同软硬件环境 （CPU、OS 和编译器）的能力，主要体现为代码的可移植性。 表 9-1 常见质量属性的描述 什么是软件质量要素？

8、它是指： （1）从技术角度讲，对软件整体质量影响最大的那些质量属性才是质量要素； （2）从商业角度讲，客户最关心的、能成为卖点的质量属性才是质量要素。 对于一个特定的软件而言，我们首先判断什么是质量要素，才能给出提高质量的具体措 施，而不是一股脑地想把所有的质量属性都做好，否则不仅做不好，还可能得不偿失。 如果某些质量属性并不能产生显著的经济效益，我们可以忽略它们，把精力用在对经济如果某些质量属性并不能产生显著的经济效益，我们可以忽略它们，把精力用在对经济 效益贡献最大的质量要素上。简而言之，只有质量要素才值得开发人员下功夫去改善。效益贡献最大的质量要素上。简而言之，只有质量要素才值得开发人员

9、下功夫去改善。 9.2 商业目标决定质量目标商业目标决定质量目标 大凡软件工程教科书为了强调质量的重要性，总是要举一些历史上发生过的重大软件质 量事故，例如航天飞机爆炸、核电站失事、爱国者导弹发生故障等等。这些事故的确不是危 言耸听，给人们敲响了质量的警钟。 学术界总是喜欢宣扬质量至上的理念，而忽视企业的商业利益，将质量目标凌驾于商业 目标之上。我不能评判这种现象是好还是坏，但是的确误导了大量读者。许多软件人员都有 “质量越高越好”的观念，这是被教科书灌输的，而不是他自己领悟出来的。 质量的最高境界是什么？是尽善尽美，即“零缺陷” 。 我曾在著作高质量程序设计指南C+/C 语言中大肆宣扬了高质

10、量程序设计的理 念，力求使 C+程序达到“零缺陷”的质量目标。尽管此书得到了许多程序员的赞同，但是 我经过反思之后改变了质量观念，我要着重指出的是： 重视软件质量是应该的，但是重视软件质量是应该的，但是“质量越高越好质量越高越好”并不是普适的真理。只有极少数软件应并不是普适的真理。只有极少数软件应 该追求该追求“零缺陷零缺陷” ，对绝大多数软件而言，商业目标决定了质量目标，而不该把质量目标凌，对绝大多数软件而言，商业目标决定了质量目标，而不该把质量目标凌 驾于商业目标之上。驾于商业目标之上。 航空航天等系统对质量要求极高，任何缺陷都有可能导致机毁人亡，所以人们不惜一切 代价去消除缺陷。在发射航

11、天器之前，只要发现任何异常，就会立即取消发射指令，直到异 常被消除为止。前苏联做得最过分，许多重大武器系统的负责人都签了生死状，系统研制成 功则获得英雄勋章，失败则被枪毙。在这种压力下没有人敢对质量有一丝松懈。 上述严格系统毕竟是少数，绝大多数普通软件的缺陷并不会造成机毁人亡这样的重大损 失，否则没有人敢从事软件开发了。在日常工作中，我们接触过的软件几乎都是有缺陷的， 即便是软件业老大 Microsoft，它的软件产品也经常出错甚至导致死机，人们骂几句后还会照 样使用有缺陷的软件。 企业的根本目标是为了获取尽可能多的利润，而不是生产完美无缺的产品。如果企业销 售出去的软件的质量比较差，轻则挨骂

12、，重则被退货甚至被索赔，因此为了提高用户对产品 的满意度，企业必须提高产品的质量。但是企业不可能为了追求完美的质量而不惜一切代价， 当企业为提高质量所付出的代价超过销售收益时，这个产品已经没有商业价值了，还不如不 开发。 企业必须权衡质量、效率和成本，产品质量太低了或者太高了，都不利于企业获取利润。 企业理想的质量目标不是“零缺陷” ，而是恰好让广大用户满意，并且将提高质量所付出的 代价控制在预算之内。 9.3 质量保证能够保证质量吗质量保证能够保证质量吗 质量保证（Quality Assurance, QA）是 CMM 和 ISO9001 最为推崇的改善软件质量的方法。 基于我亲身实践和调查

13、研究，我敢冒天下之大不讳说一句：质量保证并不能保证质量，它是质量保证并不能保证质量，它是 个美丽的谎言。个美丽的谎言。 CMM 对软件质量保证是这样描述的： 软件质量保证的目的是为管理者提供有关软件过程和产品的适当的可视性。它包括评审 和审核软件产品及其活动，以验证其是否遵守既定的规程和标准，并向有关负责人汇报评审 和审核的结果。 简而言之，质量保证活动就是检查软件项目的“工作过程和工作成果”是否符合既定的 规范。如此简单的活动为什么被冠以“质量保证”这等份量的术语呢？ 没有历史典故，经我考究，猜想是源于一个天真的假设： 过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品

14、” ， 而“差的过程”将产生“差的产品” 。假设企业已经制定了软件过程规范，如果质量保证人 员发现某些项目的“工作过程以及工作成果”不符合既定的规范，那么马上可以断定产品存 在缺陷。反之，如果质量保证人员没有发现不符合既定规范的东西，那么也可以断定产品是 合格的。 基于上述假设，质量保证人员即使不是技术专家，他也能够客观地检查和监控产品的质 量。这是质量保证方法吸引人的一面。 但是符合既定规范的东西并不意味着质量一定合格，仅靠规范无法识别出产品中可能存 在的大量缺陷。例如，即使程序员们都按照统一的编程规范来编写程序，但是编程新手的代 码可能错误百出，而高手的代码则无可挑剔，可是质量保证这种方法

15、根本无法识别新手和高 手的差距。质量保证的技术含量太低了，只能检查出肤浅的缺陷，不能对付有技术难度的缺 陷。所以单独的“质量保证”其实并不能“保证质量” 。 有个软件公司过了 CMM3 级，其质量保证人员给我发了一个 email： 我很迷茫，很想找一个人聊聊，希望你能给我点主意，化解我心中的谜团。 昨天我们公司拿到了 CMM3 的证书，但是我一点都高兴不起来。公司宣称，我们的软件 质量大大提高了，但是我却没有信心。我们的过程执行得很好，但是我觉得并没有在很大程 度上改善产品的质量。 今天还有一个项目经理跟我诉苦：前一阶段大家都忙于执行过程，但是他的产品质量令 人很不满意，尤其是测试做的很不到位

16、。我是这个项目的 SQA，所以我很理解他，但是我帮 不上他的忙。因为他们的过程执行得很好，这个项目可是通过 CMM3 级正式评估了的。 当然，执行 CMM 有不少好处，比如文档全面完整了，项目管理的可视性提高了。但是对 于我们公司而言，它并没有在根本上提高我们公司的软件能力。 比如概要设计，开发人员根本就不知道用来干吗的，怎么能指望他们写出高质量的概要 设计说明书出来。而在做技术评审的时候，他们很少能找出逻辑性的错误，只能发现一些诸 如错别字之类的小错误。我们几乎每一个配置项都要经过评审，但是大部分评审都只能发现 一些无关痛痒的问题。 公司已经通过 CMM3 级了，我认为过程执行得很好了，可是

17、软件质量仍然比较差。这是 怎么回事啊，你觉得原因在哪里？ 这个 email 很有代表性，它反映了一个共性问题：公司按照公司按照 CMM3 级的要求执行，而且级的要求执行，而且 质量人员也认为执行过程符合既定的规范，但是软件产品的质量仍然低下质量人员也认为执行过程符合既定的规范，但是软件产品的质量仍然低下。 所以我说“质量保证并不能保证质量”，这句话一点都不过分。质量保证对于保证质量质量保证对于保证质量 而言只是必要的手段，而不是充分的手段。而言只是必要的手段，而不是充分的手段。质量保证这个术语名不副实，含义模糊，我强烈 建议将“质量保证”改名为“过程检查”，免得误导国内企业。 那么怎么才能保证

18、软件的质量呢？请阅读本章第 5 节“全面软件质量管理”。 9.4 质量人员的状况质量人员的状况 9.4.1 郁闷的质量人员郁闷的质量人员 由于工作关系，我和不少软件机构的质量人员打过交道。我觉得有必要反映一下质量人 员的状况，给他们一些声援。 接上个 email，那位质量人员继续向我诉说： 我现在觉得很郁闷，CMM 评估前还有目标，评估完了冷静下来却觉得效果很差，很没劲。 项目经理向我诉苦，他们过程执行的很好，但是对产品质量很不满意，我却无能为力，我这 个 QA 还有什么用处啊！所以我现在干活没有动力，因为不能产生效益，做再多的工作也觉 得是白干。而且我现在手头有 5 个项目要跟踪，还不包括一

19、些整理培训记录的杂活，我觉得 自己连工人也不如。我有一些很好的想法却无处发挥，所以我很迷茫，很矛盾地考虑去留问 题。 类似的 email 我大概收到十来个。 在汉语字典里找不到“郁闷”这个词，它是现代人发明的。郁闷的滋味各色各样，只有 正在郁闷的人感受最真切。我发现在软件职业里，质量人员是最郁闷的一族。郁闷的共同特 征有： （1）在执行质量保证活动时，经常受别人的气，真是吃力不讨好。 （2）如果项目取得成功，主要功劳都被项目主管霸占了，领导们至多会给质量人员一些口 头上的感谢。领导们嘴上重视产品的质量，但是内心并不重视质量人员。 （3）质量人员没有实质性的权力，没有成就感，但是却对质量负有最多

20、的责任。 （4）待遇一般，看不到升迁的机会，没有盼头，要么成为打杂的，要么另寻出路。 在企业里，职位是有高低之分的，但是人人都是平等的。郁闷的滋味是很不好受的，为 啥老是让质量人员郁闷呢，这显然很不公平。我曾经做过伤害质量人员的事情，现在良心发 现，在这里道个歉，并声援他们。 两年前，我在一个软件事业部负责推广软件工程和 CMM。公司领导比较重视，给我 6 个全职人员，有充足的资金，声势浩大，那时我比较自负，很少采用协商的方式解决纠纷。 公司有专门的质量部门，定期到各事业部检查质量。由于我们事业部采用的是 CMM，而质 量部门采用的是 ISO9000 标准，我不懂他的，他不懂我的，所以产生了纠

21、纷。事业部的各级 领导都有销售压力，用他们的话说是：没有时间陪质量部门的人“玩” ，大家都有“对付” 而不是“配合”质量部门的心态。 有一次质量部门要检查某个重点项目的文档，偏偏这个项目是保密的，一方要检查一方 要保密，双方弄僵了。在事业部内部开会的时候，这个重点项目的负责人大发脾气说：我最 烦那些人，看么看不懂，还老是来检查，别说项目是保密的，就是不保密的我也不给看。大 家火得很热烈，我就火上加油给质量部门发了 email，大致意思是“你们搞 ISO9000 的人不 懂软件工程，不懂 CMM，不懂得软件开发却老是来检查软件项目，对本事业部只有干扰而 没有帮助” ，email 言词激烈。我把

22、email 发给一位和我打交道比较多的质量部人员，并抄送 给本事业部所有人员，给本部门大大地出了一口气。 过了几天，我收到质量部同事的 email，足足有两页纸。有几句话我记忆很深刻： 收到你的 email 时我十分震惊。依你的身份，当着事业部百余名员工的面，把工作上的 怨气发在我这个无辜的人的头上，我实在难以接受。 提高产品质量是我们的工作职责，我们并不想和任何人争吵。观念的差异可以通过交流、 协商的方式来解决，我不强求你接受任何东西，但真心希望能对你有所触动，并欢迎你和我 或我的同事继续探讨、交流。 我非常后悔，因为我伤害了一个十分友善而且敬业的质量部同事。而更糟糕的是，我这 个例子只不过

23、是冰山一角而已。我所认识的公司内外的质量人员都是性格温和、细致耐心的 人，他们的优点在于人格而不是技术。平心而论，他们比技术出色但是情商不高的技术人员 更值得交朋友。质量检查是他们的工作职责，谁也不会有意干扰项目，所以任何人都不应该 向他们发火。 9.4.2 路在何方路在何方 我的一位同事在干了 5 年的质量保证工作后，终于厌倦了，到某大学软件学院当老师去 了，目前看上去比较满意。 有一位生物专业毕业的、做了多年 ISO9000 的同事和我谈心，她也说很想当大学老师， 当然不教质量管理的课程，而是希望重拾她的生物专业。 那位平白无故受我怨气的质量部同事正在读 MBA，学得很好，我想她必定有更好

24、的追 求。 上节 email 的作者一边上班一边读工程硕士，她的工作任务有一些变动： 我已经转做测试了，主要原因有以下几个： 1、我们的过程质量虽然很好，但是在提高产品质量方面没有达到期望的效果； 2、测试是保证产品质量的一种重要手段，我要接触一下，从而对产品的质量有更好的 理解； 3、这段时间项目不多，我比较空闲，而且只做 SQA 的工作，有点枯燥； 4、我们公司的测试力量比较薄弱，我希望能帮忙做点什么； 5、长期以来，没有深入项目的感觉，我希望自己能够亲身去执行我们的过程，看看能 不能找出点问题； 同时，我也没有放弃 SQA 的工作，以后在做测试的同时，我会至少兼做一个项目的 SQA。我想

25、这样是一个相辅相成的过程。我希望自己能对提高软件产品质量做点贡献。 你看了 email 就知道她是一位积极上进的好员工，她靠自己的悟性在摸索解决问题的方 法。她碰到的问题我看得很清楚，绝非个别现象。问题的根源是：她公司的领导不懂得真正 有效的质量管理，使她无法发挥全职质量人员的价值。 软件行业里的人嘴上都说质量很重要，可是大多数企业并没有给质量人员提供良好的职 业发展空间。质量人员通常仅给企业起到心里安慰的作用。这样下去，有能耐的质量人员会 跑光的。 在大多数的软件企业里，男性处于支配地位，女性职位相对比较低。而质量人员通常是 女性，很多男性主管从未真正地把质量人员当成企业的宝贵人才看待，这种

26、偏见是非常有害 的。任何素质合格的员工都是宝贵的人才，很多默默无闻的人才其实是被不懂得管理的领导任何素质合格的员工都是宝贵的人才，很多默默无闻的人才其实是被不懂得管理的领导 给荒废了。给荒废了。质量人员之所以没有发挥预期的效果，不是性别缘故，主要过失在于领导者。企 业领导们要好好反省，你自己不懂质量管理，不是瞎指挥吗？ 我的建议如下： （1）无论是企业领导还是质量人员，都要好好学习全面软件质量管理方法，结合企业的特 点给出真正有效的质量管理方案。 （2）只有当企业领导采用了正确的质量管理方案，用了合格的质量人员，才可能看得到比 较明显的质量改善，才能形成良性循环。 （3）如果想让质量人员负起比

27、较重的责任，那么就要给她相应的权力。在企业中，责任和 权利是成正比的。如果质量人员的地位无足轻重，那么必然导致质量管理无足轻重。 （4）给质量人员一个适宜的升迁机会和薪资待遇，让她能够快乐地工作，而不是成天无奈 地检查质量。 9.4.3 赞美诗赞美诗 在我写这本书的时候，中国正遭受非典型肺炎（SARS）的肆虐。人们在危难之际想起了 医护人员的好处，因此涌现了许多对医护人员的赞美诗。 我碰巧在网上搜索到一位软件诗人献给质量人员的赞美诗“晚上八九点钟的太阳”，我 看了不禁喜悦和感动。我认为没有必要等到软件质量灾难降临的时候才想起质量人员，于是 摘录这首诗公布于此。诗中的“狼人”和“银弹”是软件工程

28、的典故，寓意深刻。衷心感谢 这位不知姓名的浪漫软件诗人。 晚上八九点钟的太阳 献给软件测试和质保人员 我更喜爱晚上八九点钟的太阳， 虽然人们都已把他遗忘， 但他还是艰难地悬挂在天上。 我更喜爱晚上八九点钟的太阳， 因为他将奏出黎明的交响。 没有他 又怎会呼唤出一片明亮？ 我更喜爱晚上八九点钟的太阳， 因为他会化成早上的朝阳。 没有他 又怎会有什么希望？ 我更喜爱晚上八九点钟的太阳， 因为他是上帝的臂膀。 没有他， 又怎会创造万物的光芒。 狼人望月嚎叫， 它知道 月亮映出的太阳之光， 终将化为银弹， 射入它的胸膛。 我 更喜爱 晚上八九点种的太阳。 9.5 全面软件质量管理全面软件质量管理 9.

29、5.1 模型模型 如果一个人浑身上下都没有毛病，那么他就很健康；反之如果浑身是病，那么就不健康。 所以毛病是健康的死对头。 同理，质量的死对头是缺陷，缺陷是混在产品中的人们不喜欢、不想要的东西，它对产 品没有好处只有坏处。人们常说的 Bug 就是缺陷的形象比喻。 显然，缺陷越多质量越低，缺陷越少质量越高，提高软件质量的基本手段是消除软件缺 陷。让我们看看中国郎中治病的故事，受点启发。 在中国古代，有一家三兄弟全是郎中。其中有一人是名医，人们问他：“你们兄弟三人 谁的医术最高？” 他回答说：“我常用猛药给病危者医治，偶尔有些病危者被我救活，于是我的医术远近 闻名并成了名医。我二哥通常在人们刚刚生

30、病的时候马上就治愈他们，临近村庄的人说他是 好郎中。我大哥不外出治病，他深知人们生病的原因，所以能够预防家里人生病，他的医术 只有我们家里才知道。 ” 上述故事里，郎中三兄弟是三种治病方式的代言人。相似地，提高软件质量也有三种方 式。 老大治病的方式最高明，如果人们能够预防生病的话，那么没病就用不着看医生了。提 高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开 发过程之中。主要措施是“不断地提高技术水平，不断地提高规范化水平” ，其实就是练内 功，通称为“软件过程改进” 。 即使一个人严守养生之道，身体状况良好，但总是会意外地得病的，得了病就要去看医 生。老二治

31、病的方式就是医院的模式，病人越早看病，就越早治好，治病的代价就越低。同 理，在开发软件的时候，即使人们的技术水平很高，并且严格遵守规范，但是人非机器，总 是会犯错误的，因此无法完全避免软件中的缺陷。那么怎么办呢？ 当工作成果刚刚产生时马上进行质量检查，及时找出并消除工作成果中的缺陷。这种方 式效果比较好，人们一般都能学会。最常用的方法是技术评审、软件测试和过程检查，已经 被企业广泛采用并取得了成效。 老三治病的方式代价最高，只能是不得已而为之。可在现实之中，大多数软件企业采用 老三的方式来对付质量问题。典型现象是：在软件交付之前，没有及时消除缺陷。当软件交 付给用户后，用着用着就出错了，赶紧请

32、开发者来补救。可笑的是，当软件系统在用户那里 出故障了，那些现场补救成功的人倒成了英雄，好心用户甚至还寄来感谢信。 借鉴老大、老二治病的方法，我们提炼出全面软件质量管理的模型，如图 9-1 所示。项 目中的所有人员几乎都参与了质量活动，只是介入的程度不同而已，本章后面几节将逐一介 绍这些质量活动。 图 9-1 全面软件质量管理的模型 9.5.2 质量人员的职责质量人员的职责 谁对软件质量负责？ 是全员负责。任何与软件开发、管理工作相关的人员都对质量产生影响，都要对质量负是全员负责。任何与软件开发、管理工作相关的人员都对质量产生影响，都要对质量负 责。责。所以人们不要把质量问题全部推出质量人员或

33、测试人员。 谁对软件质量负最大的责任？ 谁的权利越大，他所负的质量责任就越大。谁的权利越大，他所负的质量责任就越大。质量人员是成天与质量打交道的人，但他个 人并不对产品质量产生最大的影响，所以也不负最大的责任。 前面分析过了，如果质量人员仅仅从事质量保证活动的话，那么他对软件开发和管理的 介入就非常肤浅，对提高质量缺乏实质性贡献，最终导致他很“郁闷” 。 在图 9-1 的模型中，质量人员的主要职责是： 负责制定质量计划（很重要但是工作量比较少） ； 负责过程检查（类似于 CMM 中的质量保证） ，约占个人工作量的 20%； 参与技术评审，约占个人工作量的 30%； 参与软件测试，约占个人工作量

34、的 30%； 软件项目 X 制定质量计划 缺陷 跟踪 技术评审软件测试 过程检查 软件过程改进：提高软件技术水平和规范化水平 参与软件过程改进（面向整个机构） ，约占个人工作量的 20%； 上述工作量的比例仅供参考，在实际应用时必须根据项目的特征而定。 技术评审与软件测试关注的是产品质量而不是过程质量，两者的技术强度比过程检查要 高得多，更加容易发现缺陷。技术评审和软件测试能弥补过程检查的不足，我们不能将过程 检查、技术评审和软件测试的观念混为一谈，但是也不能把三者孤立起来。质量人员除了过质量人员除了过 程检查之外，还要参加（并监督）重要的技术评审和测试工作，这样做才富有成效。程检查之外，还要

35、参加（并监督）重要的技术评审和测试工作，这样做才富有成效。 软件过程改进是面向整个机构的，而不仅仅是针对某个项目的。由于质量人员的日常工 作主要是过程检查、技术评审、软件测试，成天与质量问题打交道，所以他能发现整个机构 的共性质量问题，因此质量人员参与软件过程改进是很有意义的。 软件过程改进一般由 SEPG（Software Engineering Process Group）负责。我曾经和不少 CMM 咨询师和 SEPG 的负责人交流过，多数人认为 SEPG 是“立法机构” ，质量小组是“执 法机构” ，两者应该彻底分开。我认为这种设想很不适合中国中小型软件机构（100 人以下） ， 企业又

36、不是国家政法机构，哪有那么多的人和钱去搞理想主义啊！ 图 9-1 的模型完全出于实用主义，所以不受 ISO9000 和 CMM 的约束。 9.5.3 制定质量计划制定质量计划 质量计划就是为了实现质量目标的计划。而质量目标则是由商业目标决定的。开发软件 产品的最终目的是为了赚钱，所以人们为提高软件质量所付出的代价是有上限的，项目负责 人当然希望代价越低越好。质量计划就是全面质量管理的行动纲领。质量计划就是全面质量管理的行动纲领。 谁制定质量计划？ 由项目核心成员和质量人员共同协商制定，主要由质量人员起草，由项目经理审批即可。 表 9-2 为软件质量计划的参考模板。 XXX 软件质量计划 1.

37、质量要素分析质量要素分析 提示：从商业利益和技术角度判断哪些质量属性是本软件的质量要素，说明为什么，这样相关人员可以把 精力集中在改善质量要素上。 质量要素优先级解释 2. 质量目标质量目标 提示：给出各个质量要素的恰当目标，既要使客户感到满意，又要使开发方承受得起。 质量要素目标 3. 人员与职责人员与职责 提示：项目中的许多人员将参与各种质量活动，说明他们的职责。 人员质量活动、职责描述 4. 过程检查计划过程检查计划 过程域、主要检查项时间或频度负责人 5. 技术评审计划技术评审计划 待评审的工作成果评审时间负责人 6. 软件测试计划软件测试计划 测试活动名称时间负责人 7. 缺陷跟踪工

38、具缺陷跟踪工具 提示：说明本项目采用何种缺陷跟踪工具，以及简要的使用约定。 8. 审批意见审批意见 提示：项目经理审批本计划 表 9-2 软件质量计划的模板 9.5.4 技术评审技术评审 技术评审（Technical Review, TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发 人员及时消除缺陷，从而有效地提高产品的质量。 技术评审最初是由 IBM 公司为了提高软件质量和提高程序员生产率而倡导的。技术评审 方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之一。 技术评审的主要好处有： 通过消除工作成果的缺陷而提高产品的质量； 技术评审可以在任何开发阶段执行，不

39、必等到软件可以运行之际，越早消除缺陷就 越能降低开发成本； 开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解， 更好地预防缺陷，一定程度上提高了开发生产率。 技术评审有两种基本类型： 正式技术评审（FTR） 。FTR 比较严格，需要举行评审会议，参加评审会议的人员比 较多。 非正式技术评审（ITR） 。ITR 的形式比较灵活，通常在同伴之间开展，不必举行评 审会议，评审人员比较少。 理论上讲，为了确保产品的质量，产品的所有工作成果都应当接受技术评审。现实中， 为了节约时间，允许人们有选择地对工作成果进行技术评审。技术评审方式也视工作成果的 重要性和复杂性而定。将重要性、复

40、杂性各分“高、中、低”3 个等级。重要性复杂性组 合与技术评审方式的对应关系如表 9-3 所示。在制定质量计划的时候，应该确定技术评审计 划，见表 9-2。 重要性复杂性组合重要性复杂性组合技术评审方式（技术评审方式（FTR, ITR） 高高FTR 高中FTR 高低FTR 或者 ITR 均可 中中FTR 或者 ITR 均可 中低ITR 低低ITR 表 9-3 重要性复杂性组合与技术评审方式的对应关系 本节重点介绍正式技术评审的流程，如图 9-2 所示。 图 9-2 正式技术评审的流程 Step2. 举行评审会议 Step1. 准备评审 2.1 主持人宣讲 2.2 作者介绍工作成果 2.3 识别

41、缺陷和答辩 2.4 讨论缺陷解决方案 2.5 会议结束决议 Step3. 跟踪与审核 第一步第一步 准备评审准备评审 评审主持人首先确定评审会议的时间、地点、设备和参加会议的人员名单（包括评 审员、记录员、作者、旁听者等） ，并告知所有相关人员（例如 email） 。 评审主持人把工作成果及相关材料、技术评审规程、检查表等发给评审员。 评审员阅读（了解）工作成果及相关材料。 第二步第二步 举行评审举行评审会议会议 Step2.1 主持人宣讲本次评审会议的议程、重点、原则、时间限制等。 Step2.2 作者扼要地介绍工作成果。 Step2.3 评审员根据“检查表”认真查找工作成果的缺陷。作者回答

42、评审员的问题， 双方要对每个缺陷达成共识（避免误解） 。 Step2.4 作者和评审员共同讨论缺陷的解决方案。对于当场难以解决的问题，由主 持人决定“是否有必要继续讨论”或者“另定时间再讨论” 。 Step2.5 评审小组给出评审结论和意见，主持人签字后本次会议结束。评审结论有 三种： （1）工作成果不合格，需要作比较大的修改，之后必须重新对其评审。 （2）工作成果合格， “无需修改”或者“需要轻微修改但不必再审核” 。 （3）工作成果基本合格，需要作少量的修改，之后通过审核即可，转向第三 步。 第三步第三步 跟踪与审核跟踪与审核 作者修正工作成果，消除已发现的缺陷。评审主持人（或者指定审查员

43、）跟踪每个 缺陷的状态。直到工作成果合格为止。 技术评审报告的模板如表 9-4 所示。 XXX 技术评审报告 1. 基本信息基本信息 提示：由评审主持人或记录员填写 成果介绍名称，版本，作者，时间等等 评审时间 评审地点 评审会议名单角色、职务 人员 A评审主持人 人员 B 2. 问答记录问答记录 提示：由评审主持人或记录员填写，主要记录评审过程中的疑问、答复、争论、处理意见 记录 A 记录 B 3. 评审结论与意见评审结论与意见 提示：由评审主持人填写 评审结论 工作成果合格， “无需修改”或者“需要轻微修改但不必再审核” 。 工作成果基本合格，需要作少量的修改，之后通过审核即可。 工作成果

44、不合格，需要作比较大的修改，之后必须重新对其评审。 意见建议 签字主持人签字 4. 缺陷跟踪与审核缺陷跟踪与审核 提示：如果使用了缺陷跟踪软件，那么无需手工填写此表，用软件生成缺陷报表就行。 缺陷描述缺陷解决方案、结果 表 9-4 技术评审报告的模板 技术评审是个团体活动，一般地，机构没有专职地技术评审人员，当需要技术评审的时 候临时组织人员就可以了。质量人员一定要参与技术评审活动（大约占其工作量的质量人员一定要参与技术评审活动（大约占其工作量的 30左右）左右） ，建议让质量人员主持那些重要的技术评审会议，免得开发人员忘记了技术评审。，建议让质量人员主持那些重要的技术评审会议，免得开发人员忘

45、记了技术评审。 9.5.5 软件测试软件测试 技术评审和软件测试的目的都是为了消除软件的缺陷，两者的主要区别是：前者无需运 行软件，评审人员和作者把工作成果摆放在桌面上讨论；而后者一定要运行软件来查找缺陷。 技术评审在软件测试之前执行，尤其是在需求开发和系统设计阶段。相比而言，软件测试的 工作量通常比技术评审的大，发现的缺陷也更多。 本书第 7 章已经深入介绍了软件测试的方法与技术，本节不再累赘。这里要着重强调的 是，软件测试、技术评审、过程检查、缺陷跟踪都是全面质量管理不可缺少的组成部分。在 制定质量计划的时候，已经确定了本项目的主要测试活动、时间和负责人，之后再考虑软件 测试的详细计划和测

46、试用例。 如果机构没有专职的软件测试人员的话，那么开发人员可以兼职做测试工作。当项目开 发到后期，过程检查和技术评审都已经没有多少意义了，开发小组急需有人帮助他们测试软 件，如果质量人员参与软件测试，对开发小组而言简直就是“雪中送炭” 。 本章强调，质量人员一定要参与软件测试（大约占其工作量的本章强调，质量人员一定要参与软件测试（大约占其工作量的 30左右）左右） ，只有这样他，只有这样他 才能深入地了解软件的质量问题，而且给予开发小组强有力地帮助才能深入地了解软件的质量问题，而且给予开发小组强有力地帮助。 9.5.6 过程检查过程检查 CMM 和 ISO9001 所述的软件质量保证，实质就是

47、过程检查，即检查软件项目的“工作 过程和工作成果”是否符合既定的规范。 “过程检查”这个词虽然没有质量保证那么动听，但是其含义直接明了，不会让人误解。 为了避免人们误以为“质量保证”能够“保证质量” ，我提议用“过程检查”取代质量保证 这个术语。 虽然本章批判了“质量保证”的浮夸，但是并没有全盘否定质量保证的好处。过程检查 对提高软件质量是有帮助的，只是它的好处没有象质量保证鼓吹的那么好而已。 例如，机构制定了配置管理规范，要求每个项目都进行版本控制，但是在项目的实际开 发过程中，许多开发人员并没有对其工作成果进行版本控制。万一版本发生混乱，必定对项 目产生负面影响。如果质量人员在过程检查时发现了这个问题，那么他就有责任要求开发人 员执行版本控制，如果开发人员不接受这个好意，那么质量人员就要向上级领导反映这个问 题，直至消除隐患为止。 再例如，机构制定了重要工作成果的文档模板（例如需求规格说明书、设计报告等） ， 要求开发人员写的文档尽可能符合模板。如果质量人员发现开发人员写的文档与机构的模板 差异非常大，那么就要搞清楚究竟是模板不合适？还是开发人员偷工减料大大简化了模板？ 符合规范的工作成果不见得就是高质量的，但是明显不符合规范的工作成果十有八九是符合规范的工作成果不见得就是高质量