软件缺陷发现

《软件缺陷发现》由会员上传分享，免费在线阅读，更多相关内容在PPT专区-天天文库。

软件缺陷发现

1测试是一项重要的缺陷发现手段还有很多手段：检查需求规格说明书、设计说明书等工作产品编写代码编译代码运行代码专职质量保证人员的工作产品大规模测试最终用户使用6种手段：同行评审测试管理评审PPQA发现项目组内部发现客户反馈

22.1同行评审（PeerReview）工作产品开发过程中，为了识别缺陷，由软件产品生产者的同行遵循已定义的规程对产品进行的技术评审产品：在定义项目软件过程时被确定，并作为软件开发计划的一部分被按排了进度；是最终产品的组成部分；是在软件开发或维护过程中产生或需要的一个可交付的文档。如：需求文档、设计文档、软件代码、单元测试产品、计划文档等同行：不局限于从事相同工作的人，而是与该工作相关的所有人员（CMMI）。如：凡是从事软件相关工作的人都可称为同行，包括软件设计人员、软件开发人员、软件测试人员、软件需求人员、项目管理人员等

3同行评审的目的：及早和高效地识别并消除缺陷，使软件更易读和可维护，减少最终泄漏到产品发布时的缺陷提高质量：相对动态测试，较易实现较高的覆盖率提高有效性：有效测试的基本原则之一：及早测试可预测性：减轻动态测试的不可控性和不可预测性培训目的：有效的评审相当于一次培训缺陷预防：为将来的项目改进提供数据和经验，不断改进开发过程、测试过程、评审过程等，在将来的项目中达到缺陷预防的目的主要工作：发现工作产品中的具体错误通过对这些错误的分类和统计，发现共同的错误类型和将来避免这类错误的方法缺陷前移

4同行评审的好处中高层：可以及时掌握项目的进展项目组：可以利用组织中最有才干的人，即使他们没有参与项目组也能发挥作用令项目组成员有一种成就感、参与感、得到认可的感觉，从而保持团队的积极性团队成员可以发展他们的技能，指导那些缺乏经验的人员通过评审更加留意缺陷，从而帮助预防缺陷

5同行评审有助于提高质量、提高生产率、降低成本使开发人员及时得到专家的帮助和指导，加深对工作成果的理解，更好地预防缺陷，从而提高开发生产率消除工作成果的缺陷，可以提高产品质量，提高客户满意度成本低：查找错误的头脑风暴无须特殊环境早期即可引入：越早消除缺陷越能降低开发成本

6原始需求正确的规格说明错误的规格说明正确的设计错误的设计对错误说明的设计正确的编码错误的编码对错误设计的编码对错误说明的编码正确的功能可改正的缺陷不可改正的缺陷潜伏的缺陷最终提交的产品需求分析阶段设计阶段编码实现阶段测试阶段随着开发进展，缺陷不断泄漏和放大；需不断评审，减少泄漏

7效率高：有效的同行评审发现的问题数可达40%左右大的问题基本都是通过这种手段发现的能定位问题发生的运因，从根本上处理AT&T的贝尔实验室引入审查后：生产率提高了14%,质量提高了10倍某大型电力交换系统：发现错误的成本降低了10倍；审查发现错误的成效是测试的20倍TRW对一个大型软件进行了研究，发现2019个由用户发现的错误导致代码变更，其中：通过代码审查可以发现62.7%通过设计审查可以发现57.7%

82.1.1同行评审与测试有些工作产品在早期就可进行同行评审，但不能测试测试不能发现某些特定类型的缺陷，如违反编程规范评审（同行评审和管理评审）是静态测试技术的重要组成部分，应在动态测试前进行。可以发现产品中70%—80%的缺陷，而动态测试发现的缺陷很难达到50%单元测试系统测试缺陷数目：20050%1005050%文档评审代码评审缺陷数目：20050%1005050%文档评审代码评审50%251350%评审的质量控制功能

9进行同行评审会花费一些时间和工作量，但会在测试中节省更多，从而降低成本对于保存精确记录的大系统，一套完整的同行评审体系能使项目在每个测试阶段出现的错误减少90%，即使综合考虑同行评审活动的成本，同行评审也会使测试成本下降50%——80%同行评审不能替代测试，反之亦然

102.1.2同行评审的种类IBM的Fagan发明同行评审较著名的同行评审模型：IEEEE1028评审微软的技术评审GillGraham审查VanEmden审查Yourdon结构化走查CMMI模型将同行评审分为三类正式评审技术审查走查

11正式评审（Inspection）由经过同行评审培训的项目经理或PPQA主持，3——8人为宜一般在完成了一个工作产品后对其进行定位并清除工作产品中的缺陷以一种正式的形式进行，如：有正式的、事先定义好的有关职责的各种角色，并遵循组织规定的标准流程

12技术审查（TechnicalReview）也称内部审查通常由技术负责人或项目经理召集，3——5人参加进行技术审查的一般时机：在工作产品的中期完成了某部分独立的工作产品时在书写草案遇到问题时就其中专门的一两项问题进行讨论和审查也可检查工作产品与规程、模板、计划、标准的符合性或变更是否被正确地执行目的：通过对开发人员的工作产品的技术审查，提出改进意见

13走查（Walkthrough）也称代码走查或代码走读审查范围：根据需求的优先级通常由管理人员来确定，主要是静态质量分析和编程规则检查。。通常是小型讨论会，两三个人参加，作者主持一般在工作产品形成的早期进行，也可在编制工作产品的任何阶段进行评估和提高工作产品的质量或教育参加者正式评审是正式的。技术审查和走查是常用的非正式同行评审方法

142.1.3同行评审的对象所有软件开发的中间和最终工作产品：产品需求规格说明书用户界面规范及设计架构设计、概要设计、详细设计、模型源代码测试计划、设计、用例及步骤项目计划，包括开发计划、配置管理计划、质量保证计划等以上所有评审涉及内容，应在编制的项目计划或小的开发计划中体现，不应也不能是临时的安排

152.1.4同行评审过程根据同行评审的重要程度，正式评审、技术审查、走查三种形式的流程和成果物的使用力度不尽相同，但主要步骤和内容大体一致作者主持人记录人评审人工作产品或注释选择评审材料修改工作产品确定评审日期邀请评审人员主持评审预备会主持正式评审会评审工作产品评审工作产品倾听提供工作产品协助复核记录缺陷评审结果搜集输入搜集输入更新计划更新计划工作产品片断邀请人员工作产品检查表规程个人缺陷检查记录统计表最终缺陷检查记录统计表修改工产品，更新日志、统计表

16正式评审流程预备：为保证评审质量，可先进行一个预备会议。作者向评审组概要介绍评审材料允许并鼓励评审组成员动手查看工作产品或开发过程中用到的检查单等预备会结束时，把文档分发给与会者，包括：要审查的工作产品参考文档工作产品评审检查表工作产品审阅情况记录表这些材料应控制在2小时内审核完成为宜。主持人负责确定什么时间召开真正的评审会议

17审查：在预备会和正式评审会之间，评审小组成员对工作产品进行彻底检查，并依据相关标准和准则评审工作产品，记录发现的缺陷、问题种类与严重程度、所用的时间等评审：在预定的正式评审时间内（会议时间控制在2小时内），评审小组成员以会议形式聚在一起，依次对产品进行检查。每个评审员花一定时间（一般十几分钟）指出问题，并和作者确定问题和定义问题的严重程度。注意：评审过程中是发现错误，不是现场改正。会议中，记录员详细记录每个已达成共识的缺陷，包括缺陷的位置、简短描述缺陷、缺陷类别、该缺陷的发现者等。未达成共识的缺陷也将记录下来，加入“待处理”或TBD（ToBeDiscussed）标识，评审主持人将指派作者和评审员在会后处理评审会议中未能解决的问题。

18书写评审报告：评审主持人根据记录员的记录和自己的总结，在一天内写出评审报告，内容包括：根据评审专家个人的输入创建总的问题清单加入会议中发现的问题剔除经确认属于重复或无效的问题共同确定需要修改的问题及修改的程度返工：作者根据评审报告的决议，负责解决确定的所有缺陷和问题。跟踪：评审组长必须确保所提出的每个问题都得到了圆满解决。必须仔细检查对文档的每个修正，以确保没有注入新的错误。

19申请评审评审计划启动会议评审准备结束跟踪返工小组评审会议联系协调者；确定入口准则；选择审查者；制定评审计划；设计评审视角；准备评审包；设置测量目标简短(5_30分钟）；沟通评审事宜评审文档；各自记录条款；最好提前一天协调验证返工；关闭所有条款；整理条款；修改目标文档；记录发现条款；协调者推动会议；会议时间很重奥正式评审流程

20技术审查流程准备：评审组长（通常是项目经理）要求项目组成员提供需要考虑的特定问题并分发评审材料，确定评审重点：需要注意的特定问题需要满足的特殊标准或规格说明需要审查的接口或依赖关系评审：评审人各自审查评审材料，目的是发现错误，而非改正（通常每次评审会不超过小时）。评审组组长应在一天内写出评审报告。评审会议内容包括：汇总个人发现的问题加入会议中发现的问题

21跟踪：作者负责解决评审报告中的所有错误及问题。评审组长检查所提出的每个问题是否都得到了解决。组长起草评审发现报告：问题或弱项清单小组对如何解决这些问题或弱项清单的建议行动事项

22走查流程形式更简单。主要有两种方式：参与者驱动法：参与者按照事先准备好的列表，提出他们不理解的术语或认为不正确的术语。作者必须回答每个质疑，要么承认有错误，要么对质疑做出解释文档驱动法：作者向评审人仔细解释文档（或代码）。可将评审的内容（如代码、架构图、业务逻辑图等）用投影仪投射到屏幕上，作者对工作产品进行讲解，评审人不时针对事先准备好的问题或解释过程中发现的问题提出质疑可能比参与者驱动法更有效，往往能检查出更多错误经验表明，许多错误是由文档讲解着自己发现的走查过程中，每个评审人都要记录错误或建议，会后要整理会议记录，形成走查报告。工作产品的作者可根据自己的思路质疑走查报告

23对代码的同行评审就是代码走查。可用投影仪打出关键代码位置与参与人员一起读也可几个开发人员一起进行交叉走查选定的进行代码走查的范围根据需求的优先级来具体确定

24同行评审的结果正常：评审专家作好了评审准备，会议正常，结果明确，不需要再次评审延期：30%以上评审专家没有作好准备，会议无法正常进行，需要确定再次评审时间取消：在初审阶段就发现很多问题，需要作者进行修正，然后再进行第二次同行评审

252.1.5同行评审方式的比较种类正式评审技术审查走查目的以较详细的力度，定位并去除工作产品中的缺陷表明工作产品与规约、计划、标准的符合性或变更被正确执行了评估、提高工作产品，教育参加者入口准则工作产品符合已建立的准备准则发布了评审目的，工作产品就绪，作者准备好工作产品计划中标识时机工作产品全部完成完成独立的章节架构、蓝图、草稿规模3——8人3——5人2——3人评审材料相对较少中等或较多，根据评审目的确定中等准备时间3——5天2天主持人专职主持人小组长/组长作者变更验证主持人验证返工组长验证，作为评审报告一部分由其它项目控制手段执行成果物缺陷清单和度量元总结技术评审报告，包括缺陷清单及行动计划走查报告，缺陷记录及改进建议

262.1.6同行评审方式的选择对于同一个工作产品，根据所处的阶段可使用不同的评审方式工作产品刚勾画、起草时——走查完成了某一个单独的章节时——技术审查整个产品完成时——正式评审

27各工作产品通常采用的评审方式及参加人员：项目总体计划走查项目经理、产品经理、需求提出者、市场或销售代表、技术负责人、质量保证工程师、高层技术管理者、过程管理者用户需求说明书走查需求分析师、项目经理、架构师、设计师、系统测试工程师、质量保证经理、用户或市场代表、文档编写者、业务专家、技术支持代表产品需求规格说明书正式评审需求分析师、项目经理、架构师、设计师、系统测试工程师、质量保证经理、用户或市场代表、文档编写者、业务专家、技术支持代表

28项目已定义过程正式评审过程改进组负责人、过程改进工作组成员、管理级的过程拥有者、使用过程的实践者的代表开发计划技术审查创建者、项目经理、维护者、程序员系统测试计划技术审查测试工程师、程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试）、质量保证代表系统测试用例走查测试工程师、程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试）、质量保证代表各工作产品通常采用的评审方式及参加人员：

29概要设计说明书正式评审架构师、需求分析师、设计师、项目经理、集成测试工程师集成测试计划技术审查测试工程师、程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试）、质量保证代表详细设计说明书正式评审设计师、架构师、程序员、集成测试工程师各工作产品通常采用的评审方式及参加人员：

30单元测试计划走查测试工程师、程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试）、质量保证代表代码走查程序员、设计师、单元测试工程师、维护者、需求分析师、编码标准专家集成/验收测试记录和报告走查测试工程师、程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试）、质量保证代表各工作产品通常采用的评审方式及参加人员：

31用户使用手册走查文档编写者、需求分析师、用户或市场代表、系统测试工程师、维护人员、设计师、用户教育设计师、培训师、技术支持代表用户界面设计技术审查用户界面设计师、需求分析师、用户、应用领域专家、可用性或人体专家、系统测试工程师项目总结报告技术审查项目经理、产品经理、需求提出者、市场或销售代表、技术负责人、质量保证工程师、高层技术管理者、过程管理者各工作产品通常采用的评审方式及参加人员：

322.1.7同行评审注意事项一次针对产品需求的同行评审定在某日上午9:00——11:00进行。之前邮件通知了与会人员，未发放评审材料。邀请了两位技术负责人，其他都是不很了解技术和评审过程与意义的管理人员，没有安排专人记录。结果可能是——会上，多数管理人员按个人喜好与想法来评价软件的优缺点，并对该软件的开发人员进行评论，提出了偏离评审会议主题的各种意见，导致会议时间延长到4小时。软件中存在的问题很少被关注。主持人宣布会议主题后，作者简述产品需求，评审提出自己的意见。评审员小李说：“关于……需要改进。”其他人也参与进来。“这需要A项目组配合修改，A组负责人小张说说是否可行，打算怎么改。”小张提出自己的想法及改进方法，几个同行说出自己的想法，有时不一致，开始解释和说明……该问题占用了近40分钟时间。继续……2小时后，需求评审只进行了一半。会议没有得到评审结果就宣告结束，只能下次继续。会议过程中没有任何记录。

33出了什么问题？没有专门通知到个人没有预先下发被评审的工作产品和检查单会议焦点不在解决问题上，而是转移到了如何解决问题主持人没经验，没能很好主持和控制会场局面没有作缺陷记录和发现工作量的记录

34同行评审应遵循的原则123准则同行评审准备时间等于或大于开会时间同行评审期间发现的缺陷数量应是同行评审准备期间发现的缺陷数量的2倍以上同行评审发现缺陷的效率是测试发现缺陷的3倍同行评审需要管理层的支持，否则，即使是目标明确的开发组成员也会抵制同行评审同行评审是结构化的过程，涉及许多参与人员的角色，选择评审专家时要注意其中的互补性对每种类型的同行评审，应制定通用的工作产品评审检查表，必要时可适当裁减以适应特定项目的要求

35评审开始前，评审人应准备好自己所关注和将提出的问题评审的重点在于发现问题，而非解决问题对技术人员工作的审查应由技术人员进行，管理人员别参与。但应将评审结果和解决发现问题的日期通知管理人员评审的过程是对事不对人的，例如，可以说“这个假设是错误的”，不能说“你的假设根本不对”成功的审查要求所有参与者精力高度集中，可能会令人十分疲惫，因此每个审查阶段最好不超过2个小时。每个人每天最好只参加一个阶段审查将评审数据输入到组织度量库中，用于监测评审效果，并管理和跟踪产品。例如：在全过程使用同行评审，要占10%的开发工作量每20页叙述性文档，需要40人时每12页概要设计，需要30人时每1000行代码，需要55人时使用一段时间后，评价一个项目或一个组织的审查结果需要1人月同行评审应遵循的原则

36同行评审通过的准则最小准则工作产品已经返工和确认主持人已经发布审查报告基于组织的度量元或早期的审查，可以为这类工作产品设置出口准则剩余主要缺陷数的估计是否在限定范围内剩余次要缺陷数的估计是否在限定范围内变更数量在限值范围内（例如：IBM某部门的指南规定，变更代码应少于评审代码的5%）

372.1.8同行评审的经验共享所有缺陷最终都应追溯到需求，因为最严重的错误是“导致程序无法满足需求”的错误软件开发人员和管理人员首先应该尽早地和不断地进行软件质量保证活动（如需求和设计阶段的同行评审和走查等）软件开发人员应避免检查自己的程序，利用同行评审的方式对代码进行审查在进行各种分析和修复工作中，要充分注意修复工作所产生的影响效果和波及效果统计表明约有６０％的错误是在设计阶段之前注入的，且修正一个软件错误所需的费用将随着软件生存期的进展而上升程序中的大部分错误往往是在一小部分模块中发现的，遵循“二八定理”缺陷会掩盖会加重缺陷。遵照规范化的方法仔细复查和测试每个小程序模块，尽早排除缺陷。测试不能避免缺陷发生，只是一种补救。

382.1.9同行评审的质量根据WatteHumphrey于1998年提出的经验数据，设计阶段同行评审工作量应占该阶段工作量的1/3或以上，代码评审工作量要占到编码和单元测试阶段的工作量1/3以上。若它们都只占到15%，此时同行评审的质量系数仅为0.5业内通用质量准则：设计同行评审工作量应占设计阶段总工作量的1/3以上,其质量准则为：设计文档同行评审应至少发现3个缺陷/页。经评审修改后，缺陷清除率1级100%，2级100%，3级80%以上，残留缺陷密度控制在0.5个/页以下。代码同行评审工作量应占实现阶段总工作量的1/3以上。同行评审准备过程发现的缺陷数应是同行评审会上发现的缺陷数的2倍以上。

39建议的同行评审效率如果软件开发全过程中使用同行评审及审查，它们的总工作量要占开发工作量的10%同行评审准备效率需求250行（5页）/小时概要设计200行（4页）/小时详细设计150行（3页）/小时源码150行（无注释）/小时同行评审会议效率每20页叙述性文档，需40人时每12页概要设计，需30人时每1000行代码，需55人时

40同行评审覆盖率对需求的同行评审覆盖率要求100%对设计的同行评审覆盖率要求100%对系统和验收测试用例的同行评审覆盖率要求100%对代码的同行评审覆盖率要求不少于30%新编代码的关键部位和关键算法要进行100%的同行评审（该比例不能放宽）非新编代码采取采样评审，采样不少于25%

412.1.10评审常见问题根据Humphrey的经验，审查不能发挥作用的原因大致有：最大的问题是进度紧张且管理重视不足，使得审查流于形式实施审查的方法不当准备不足参与人员太多或不能胜任或有管理人员参与一次涵盖的内容太多在记录会议中试图修复问题记录会议拖沓冗长对个人进行评价

42文化问题现象1：进度驱动而非质量驱动。不重视质量，评审时间被一再挤压现象2：管理层没有为评审明确期望的目标现象3：一些开发组人员拒绝评审他人的工作或合作现象4：人身攻击和讽刺很普遍，作者处于防卫状态现象5：评审中收集的数据没有在其它任何地方使用

43准备问题现象1：项目计划中没有列入大的评审工作现象2：没有接受培训现象3：评审人员没有提前阅读文档并提出大量问题现象4：文档质量太差焦点问题现象1：没有遵循2/8原则注意评审的重点现象2：就某个文档进行孤立评审，没有对照已有成果和标准现象3：会议上过多讨论问题如何改正现象4：评审与评价混淆

44人员问题现象1：评审人员选择不合理现象2：评审人员搭配不合理现象3：评审专家的状态现象4：管理者要求参加他们不应参加的评审效率问题：现象1：发现了太多的缺陷现象2：在评审会议上重新讨论很久以前的决定，或质疑工作产品的背景现象3：评审人员选择了不恰当的准备方法或分析技术现象4：注意力不集中，会议跑题

45效果问题现象1：评审者总是发现同样的问题现象2：评审的有效性无法很好度量现象3：什么问题都完全靠会议讨论来解决现象4：评审内容遗漏了关键部分

46几个高效的同行代码评审最佳实践一次评审量要低于200–400行代码每小时低于300–500KLOC检查率代码评审不要超过60-90分钟，反之，评审代码所花的时间不得低于五分钟，就算代码只有一行确定在评审开始之前代码开发者已经注释源代码了为代码评审创建可定量化的目标，并获取制度，这样您就可以改进流程了

472.2软件测试广义的测试：验证和确认。软件生命周期内所有的检查、评审、确认活动验证：用数据证明是否在正确地制造产品，强调过程的正确性确认：用数据证明是否制造了正确的产品，强调结果的正确性狭义的测试：检查代码、文档的质量问题，努力发现问题，进行客观质量评价测试是为了找出缺陷，但同时，也可以通过对缺陷的度量和统计，分析缺陷产生的原因和分布特征，分析产品的质量、工作效率，诊断开发过程中的问题，并通过改进各个开发过程提高过程能力，最终降低缺陷数量和缺陷密度没有发现错误的测试也是有价值的

482.2.1测试的度量搜集与测试活动相关的规模、工作量、进度、成本、质量等方面的数据和信息规模：测试的模块数，代码行数，测试用例数，测试文档页数等工作量与成本：计划/实际测试总工作量，用例编写/执行管理、缺陷修改/验证工作量，测试效率，返工效率，评审工作量/效率，计划/实际成本，投入人数等进度：计划开始/结束时间，实际开始/结束时间，进度偏差，计划/实际周期，已经通过的测试用例数，已经集成的构件/功能数，关闭的问题数，用例测试通过率等质量：各级缺陷的个数，修复/残留缺陷数，打开/关闭缺陷数，打开/关闭时间，缺陷密度，清除率等

49以上常用度量元中，更看重缺陷数据的统计分析，对测试发现的缺陷，按照缺陷严重程度、注入阶段、发现阶段、修复阶段、缺陷性质、所属模块等方面进行分类和统计。其中对缺陷管理更有实际价值的：客户反馈缺陷：即漏测，可衡量测试人员的结果绩效。也可发现一些可能在未来会反馈回来的问题模块缺陷密度：通常找到缺陷最多的地方也是潜在缺陷最多的地方遗留缺陷数：与之前拟定的交付标准比对。被允许留下的缺陷一般也是下一阶段启动任务时开发的首要任务测试用例有效性：可规范测试活动，提高测试用例质量。用例状态：通过、完成担有错误、失败、阻塞、忽略

50测试度量信息示例序号度量对象度量元单位采集周期采集/计算方法分析方法作用1客户发现的缺陷缺陷个数个交付/维护阶段直接统计主要用于80/20分析，找出客户发现的最多的20%的缺陷类型分析客户的关注点在哪，为什么能发现这些类型的缺陷，而我们没测出来。用于知道缺陷管理过程改进2单元测试和系统测试测试效率个/小时编码/系统测试阶段缺陷个数/相应阶段的工作量与项目计划目标对比建立测试活动的投入产出模型，以估计为了达到项目的质量目标而需要的测试工作量3各级别严重程度的缺陷缺陷个数个系统测试阶段直接统计与项目计划目标对比判断是否达到测试结束与产品发布准则

512.3管理评审(ManagementReview)评审包括管理评审和技术评审。同行评审属于技术评审关注点不同：管理评审关注计划可行性和组织的有效性技术评审关注产品的正确性，检查工作产品是否符合规定的要求参与人员和目的不同：管理类评审：参加者主要为管理人员，包括高级经理、项目经理、客户代表（不一定每次都参加）、下一阶段参与的人员等，还可能涉及财务核算人员，目的是解决管理问题，通常是为管理行动提供信息，要得出管理结论，如项目立项评审、里程碑评审、项目的结题审查、项目中进行的过程审查技术类评审：一般不要求管理人员参加，目的是找出缺陷或选择技术方案，如需求评审、设计评审、代码走查、测试用例的评审等

52在项目计划中已列出了管理评审要评定的内容，具体评审过程不超过半小时，真正的评审可能只有几分钟。管理评审的前提：本阶段所涉及的所有要评审的工作产品都已经作了技术评审，由项目经理和PPQA组织填写相应的评审检查表管理评审的对象：组织的过程、项目数据、质量管理体系等管理评审的时机：顾客要求和期望的变化，先进技术的出现，产品标准变化，组织结构及职责变化，组织运行机制变化，新技术、新工艺、新设备、新生产线采用引起资源的变化；最高管理者认为必要时

53管理评审的特点：高层次性：由管理者主持，过程管理负责人员参加，相对高层次的正式评价活动战略性：从战略的眼光来审视包括目标在内的整个经营活动是否适宜，从战略的高度来审时度势，决策发展方向风险性：评审的结果可能引起组织对质量方针、质量目标、质量管理体系的重大改进，而组织的外部环境具有多变性、不可控性和复杂性潜伏着许多不确定性因素，因此，这种改进不能冒一定的风险

54里程碑评审全面地对项目组外部的成员展示工作产品的完成情况及进展、费用等情况，同时高级经理确定项目是否可以进入到下一阶段目的：按照计划（项目计划中已经列出要评定的内容）评审当前项目的进展，审查下一个阶段的计划，处理特定的问题等过程：按照项目计划，在里程碑点进行评审。参与人员包括项目经理和主要的项目相关人员，还包括项目组以外的管理决策层。在会议前解决主要问题，并审查要交付的产品。通过讨论，对评审问题达到一致，标识行动项注意：是否全面评价了项目组的进展，是否对项目组外的相关人员展示了项目组的进展？项目计划中是否已经列出要评定的内容？本里程碑阶段涉及的所有要评审的工作产品是否都已作了技术评审？

55同行评审里程碑评审目的发现并解决技术问题评价当前的工作并批准下一阶段的计划参与人员技术同行，最好没有领导项目组以外的管理人员时间点项目运行中的任何时间点在确定的时间点举行，同行评审通常作为里程碑评审的输入

56同行评审报告

57同行评审报告

58同行评审检查单

59同行评审检查单

60管理评审报告

61管理评审报告

622.4PPQA发现PPQA：Product&ProcessQualityAssurance，产品过程质量保证，简称QA。按照可应用的过程描述、标准和规程客观地评价执行的过程、工作产品、服务不仅检查工作产品的规范性和符合性，还要按照公司的标准和规范评价开发中涉及的各个过程QA人员不仅要知道过程，还要有更多的项目管理经验、开发经验、具体的技术的经验

63QA的工作评价过程QA要了解过程中易犯错误的关键点观察生命周期每个阶段的入口条件，检查过程中的事情是否都做了根据CMMI，评价工作包括：需求管理过程、项目策划过程、产品开发过程、项目监督与控制过程（可定期进行）、配置管理过程（可定期进行）、集成项目管理过程、度量与分析过程、评审、培训、组织过程定义

642.4.1QA流程初始状态协助建立项目已定义过程制定质量保证计划评审质量保证计划评价过程、工作产品和服务通报并确保解决不符合问题，维护质量保证记录结束适合项目的各种文档《不符合问题状态跟踪表》和各种报告《不符合问题状态跟踪表》和各种报告质量保证计划

652.4.2QA工作内容公司在进行CMMI改进过程中，咨询师问QA：“你认为QA在你们公司中相当于什么角色？老师？警察？医生？”QA小张：我觉得QA像警察，需要严格检查项目组的过程和产品QA小刘：我觉得QA像这三个角色，老师可以知道项目组工作，警察可以评价开发的过程和产品，医生可以帮助项目组想办法解决问题QA的角色

66评价过程评价产品与服务主要是评价产品与服务是否规范化，是否存在不符合问题。要求：在里程碑处以及交付用户前，评价工作产品检查审计工作协助项目组织审计工作的开展，并监督审计工作的执行，因为审计也是预防和发现缺陷的重要手段，是质量保证的工具其它日常活动帮助项目组加强对公司规范和标准的理解和使用协助项目经理选择适合项目的过程、规程和模板制定各种评审检查单协助项目经理制定项目计划协助项目经理组织评审活动协助项目经理进行组间协调工作

67对QA的要求具备一定的知识和技能。有不断学习、提高自我的精神具有公平公正的素质有自信，有较强的沟通能力

682.4.3QA发现的问题在整个项目开发过程中，有些过程和产品经常出现问题，需要QA特别关注，并最好提前提醒项目组注意项目计划制定不合理。QA要尽早跟进项目组的进展，监督计划制定的过程，包括开发计划、风险管理计划等维护需求的可追踪性和一致性容易出现的问题。需求难免变更，一旦入了基线，这些变更需要经过申请、审批、批准后才能执行配置管理容易出现问题其它不符合问题。如：项目经理明确表示无法解决的问题QA提交问题2天/周后，项目组未开始解决问题超过了问题解决期限2天/周后，仍未解决的问题对于影响重大的问题，QA在报告项目经理的同时，报告高层经理，以便尽快解决，降低项目风险如果提交问题解决的时间需要1周，那么问题提交2天后，项目组仍未开始解决；如果问题解决需要2周，那么问题提交4天后，项目组仍未解决；依此类推

692.4.4QA工作机制不符合项处理机制：对发现的问题有合理的处理和报告机制QA发现项目执行的不符合项，填写“不符合问题处理单”，将发现的缺陷和问题优先报告给直接责任人和项目经理，尽可能在项目组内部解决问题评价结果中不易理解或有分歧的地方，QA有义务解释和沟通若评价的结论或发现被证明有误或疏漏，QA需修改相关评价结果，并重新发送给相关人员对项目组不能解决的问题，需逐级报告给高级经理，直至问题解决。期间，使用“不符合问题状态跟踪表”进行跟踪对每个编号的问题，都应有对应的不符合问题处理单进行详细描述实际上是一种记录缺陷的方式

70

71QA工作报告机制。在评价过程或工作产品（和服务）后，无论是否通过，QA都要向相关负责人报告评价结果评价后2天内，QA把评价发现的问题填写到《不符合问题状态跟踪表》的“不符合问题处理单”中，也可将其分成两个单独的文件，反馈给相关活动/工作产品的负责人，并将不符合问题同步到《不符合问题状态跟踪表》注意：若是邮件形式通报，需直接发送给项目经理和责任人评价后，QA最好当天将评价发现的问题填写到缺陷管理系统中，并以适当形式通知相关活动/工作产品负责人和项目经理QA每双周填写“QA双周报”，汇报近两周的活动情况并发送给项目经理、高层经理、项目组成员和配置管理员在里程碑处，QA对项目的阶段工作进行总结，从缺陷管理系统中提取本阶段的问题及处理情况，生成“QA阶段评价报告”，作为里程碑评审的参考资料。首先提交给项目经理，由项目经理或总其它资料后提供给评审人员

72问题跟踪和验证。一般使用《不符合问题状态跟踪表》发现问题后和责任人及项目经理沟通将问题记载通报和项目组协商确定解决时间和负责人在解决时间将到时，提前提醒项目组，若正在修改，可及时了解当前的解决情况到了计划的解决日期，验证项目组的解决情况。对不符合要求的问题，要和项目组协商，继续修改，直至验证通过。有争议的问题可直接上报给高层领导

732.4.5QA应遵循的原则评价开发中所有工作产品，但可以区分重点。入基线的产品、计划都必须是评价重点评价项目组裁减后的所有过程开发过程都要检查评价时要按照检查单和一定的抽样准则执行评价工作在组织内要定义抽样的原则对评价的结果，首先在组内解决，且不管是否有问题，都要通报相关人员对发现问题的进行分类分析和汇总执行QA要有检查单有检查就要有记录，无论是否发现问题有问题就要跟踪直至关闭

742.4.6QA的组织形式让公司为难的一件事。需考虑公司实际情况最好组建独立的QA部门，有专职的QA人员，考虑项目具体情况，合理调配QA人员，保证资源的充分利用QA人员深入到项目组，了解项目实际情况QA组定期召开例会，根据各自实际工作总结经验教训，将好的实践形成规范或指南，让所有QA遵守和参考，以避免可能重复的过程、方法、工具的研究若让项目组的成员兼职QA：难保公正公平，失去了QA的重要作用若让测试人员兼职QA：在开发过程中可行，但QA也要评价验证和确认过程（包括测试）

752.4.8QA工作的度量投入的工作量占项目总体工总量的比例：正常情况下，QA工作量和配置管理工作量应占项目组总体工作量的5%以内发现的不符合问题数量：过多或过少都要考虑原因。一般，过程稳定后，QA发现的不符合问题数，应等于项目组以人月数计算的工作量。总结并提供经验数量对公司的有关过程和标准提出改进建议数量

762.4.7对QA的误解QA和测试人员负责产品质量。软件出现问题是QA和测试人员的责任——“软件质量保证”不能保证软件的所有质量QA就是编写文档和干零杂工作的人——对QA的要求很高QA只会站在组外品头论足、挑毛病——QA从事的都是建设性的、高附加值的工作QA把问题背后汇报给高层领导，是只知道向管理者打“小报告”的告密者——要先和项目经理及负责人协商，确认后再将QA报告完全公开地发送给项目相关人员QA就是关心开发过程是否规范，不关心产品质量，不关心技术——要过程与质量并重

772.5项目组内部发现项目经理的一个主要任务就是项目跟踪和监控，从而发现开发过程中的一些重要或隐蔽的问题。针对这些问题，首先考虑项目组内部解决，无法解决、需要领导介入帮助解决的，可通过问题报告、周报、周例会记录等各种报告形式向上级反映项目组成员在开发过程中也会发现一些问题，可反馈给项目经理，统一记录在问题报告中

782.6客户反馈客户通过电话、邮件、访问售后服务系统等反馈来的信息，是对产品进一步升级换代和改进的重要依据，也是缺陷发现的最后一道屏障可根据客户的反馈进行分析。如：客户关注的主要是什么问题客户的操作熟练程度。可考虑改进用户使用培训方面问题客户经常发现一些在本地环境无法重现的问题。应考虑是否内部测试环境和客户实际环境有差异，或使用习惯不同客户反馈的缺陷优势可能是新的需求。考虑改进需求分析客户反馈的缺陷是否由于版本更新出错引起的，后期可考虑改进更新方法测试遗漏的bug占测试人员发现的bug的百分比，据此确定测试人员的工作效果，并起到对测试人员的监督作用针对客户的反馈进行过滤，确定是否修改及修改的优先级

79小结常用缺陷发现手段：同行评审测试管理评审PPQA发现项目组内部发现客户反馈有效的同行评审发现的问题数可以占到40%左右，大的问题基本都是同行评审发现的传统意义上的测试发现和解决的问题数一般可占到35%，退化到了第二位