软件缺陷发现.ppt

《软件缺陷发现.ppt》由会员分享，可在线阅读，更多相关《软件缺陷发现.ppt（80页珍藏版）》请在三一文库上搜索。

1、软件缺陷发现,测试是一项重要的缺陷发现手段 还有很多手段： 检查需求规格说明书、设计说明书等工作产品 编写代码 编译代码 运行代码 专职质量保证人员的工作 产品大规模测试 最终用户使用,6种手段： 同行评审 测试 管理评审 PPQA发现 项目组内部发现 客户反馈,2.1同行评审（Peer Review）,工作产品开发过程中，为了识别缺陷，由软件产品生产者的同行遵循已定义的规程对产品进行的技术评审 产品：在定义项目软件过程时被确定，并作为软件开发计划的一部分被按排了进度；是最终产品的组成部分 ；是在软件开发或维护过程中产生或需要的一个可交付的文档。如：需求文档、设计文档、软件代码、单元测试产品、

2、计划文档等 同行：不局限于从事相同工作的人，而是与该工作相关的所有人员（CMMI）。如： 凡是从事软件相关工作的人都可称为同行，包括软件设计人员、软件开发人员、软件测试人员、软件需求人员、项目管理人员等,同行评审的目的：及早和高效地识别并消除缺陷，使软件更易读和可维护，减少最终泄漏到产品发布时的缺陷 提高质量：相对动态测试，较易实现较高的覆盖率 提高有效性：有效测试的基本原则之一：及早测试 可预测性：减轻动态测试的不可控性和不可预测性 培训目的：有效的评审相当于一次培训 缺陷预防：为将来的项目改进提供数据和经验，不断改进开发过程、测试过程、评审过程等，在将来的项目中达到缺陷预防的目的 主要工作

3、： 发现工作产品中的具体错误 通过对这些错误的分类和统计，发现共同的错误类型和将来避免这类错误的方法,缺陷前移,同行评审的好处,中高层：可以及时掌握项目的进展 项目组： 可以利用组织中最有才干的人，即使他们没有参与项目组也能发挥作用 令项目组成员有一种成就感、参与感、得到认可的感觉，从而保持团队的积极性 团队成员可以发展他们的技能，指导那些缺乏经验的人员 通过评审更加留意缺陷，从而帮助预防缺陷,同行评审有助于提高质量、提高生产率、降低成本 使开发人员及时得到专家的帮助和指导，加深对工作成果的理解，更好地预防缺陷，从而提高开发生产率 消除工作成果的缺陷，可以提高产品质量，提高客户满意度 成本低：

4、 查找错误的头脑风暴 无须特殊环境 早期即可引入：越早消除缺陷越能降低开发成本,随着开发进展，缺陷不断泄漏和放大；需不断评审，减少泄漏,效率高： 有效的同行评审发现的问题数可达40%左右 大的问题基本都是通过这种手段发现的 能定位问题发生的运因，从根本上处理 AT&T的贝尔实验室引入审查后：生产率提高了14%,质量提高了10倍 某大型电力交换系统：发现错误的成本降低了10倍；审查发现错误的成效是测试的20倍 TRW对一个大型软件进行了研究，发现2019个由用户发现的错误导致代码变更，其中： 通过代码审查可以发现62.7% 通过设计审查可以发现57.7%,2.1.1同行评审与测试,有些工作产品在

5、早期就可进行同行评审，但不能测试 测试不能发现某些特定类型的缺陷，如违反编程规范 评审（同行评审和管理评审）是静态测试技术的重要组成部分，应在动态测试前进行。可以发现产品中70%80%的缺陷，而动态测试发现的缺陷很难达到50%,评审的质量控制功能,进行同行评审会花费一些时间和工作量，但会在测试中节省更多，从而降低成本 对于保存精确记录的大系统，一套完整的同行评审体系能使项目在每个测试阶段出现的错误减少90%，即使综合考虑同行评审活动的成本，同行评审也会使测试成本下降50%80% 同行评审不能替代测试，反之亦然,2.1.2同行评审的种类,IBM的Fagan发明同行评审 较著名的同行评审模型： I

6、EEEE 1028评审 微软的技术评审 Gill Graham审查 Van Emden审查 Yourdon结构化走查 CMMI模型将同行评审分为三类 正式评审 技术审查 走查,正式评审（Inspection）,由经过同行评审培训的项目经理或PPQA主持，38人为宜 一般在完成了一个工作产品后对其进行 定位并清除工作产品中的缺陷 以一种正式的形式进行，如：有正式的、事先定义好的有关职责的各种角色，并遵循组织规定的标准流程,技术审查（Technical Review）,也称内部审查 通常由技术负责人或项目经理召集，35人参加 进行技术审查的一般时机： 在工作产品的中期 完成了某部分独立的工作产品时

7、 在书写草案遇到问题时就其中专门的一两项问题进行讨论和审查 也可检查工作产品与规程、模板、计划、标准的符合性或变更是否被正确地执行 目的：通过对开发人员的工作产品的技术审查，提出改进意见,走查（Walkthrough）,也称代码走查或代码走读 审查范围： 根据需求的优先级通常由管理人员来确定，主要是静态质量分析和编程规则检查。 通常是小型讨论会，两三个人参加，作者主持 一般在工作产品形成的早期进行，也可在编制工作产品的任何阶段进行 评估和提高工作产品的质量或教育参加者,正式评审是正式的。技术审查和走查是常用的非正式同行评审方法,2.1.3同行评审的对象,所有软件开发的中间和最终工作产品： 产品

8、需求规格说明书 用户界面规范及设计 架构设计、概要设计、详细设计、模型 源代码 测试计划、设计、用例及步骤 项目计划，包括开发计划、配置管理计划、质量保证计划等 以上所有评审涉及内容，应在编制的项目计划或小的开发计划中体现，不应也不能是临时的安排,2.1.4同行评审过程,根据同行评审的重要程度，正式评审、技术审查、走查三种形式的流程和成果物的使用力度不尽相同，但主要步骤和内容大体一致,正式评审流程,预备：为保证评审质量，可先进行一个预备会议。 作者向评审组概要介绍评审材料 允许并鼓励评审组成员动手查看工作产品或开发过程中用到的检查单等 预备会结束时，把文档分发给与会者，包括： 要审查的工作产品

9、 参考文档 工作产品评审检查表 工作产品审阅情况记录表 这些材料应控制在2小时内审核完成为宜。 主持人负责确定什么时间召开真正的评审会议,审查：在预备会和正式评审会之间，评审小组成员对工作产品进行彻底检查，并依据相关标准和准则评审工作产品，记录发现的缺陷、问题种类与严重程度、所用的时间等 评审：在预定的正式评审时间内（会议时间控制在2小时内），评审小组成员以会议形式聚在一起，依次对产品进行检查。每个评审员花一定时间（一般十几分钟）指出问题，并和作者确定问题和定义问题的严重程度。注意：评审过程中是发现错误，不是现场改正。 会议中，记录员详细记录每个已达成共识的缺陷，包括缺陷的位置、简短描述缺陷、

10、缺陷类别、该缺陷的发现者等。未达成共识的缺陷也将记录下来，加入“待处理”或TBD（To Be Discussed）标识，评审主持人将指派作者和评审员在会后处理评审会议中未能解决的问题。,书写评审报告：评审主持人根据记录员的记录和自己的总结，在一天内写出评审报告，内容包括： 根据评审专家个人的输入创建总的问题清单 加入会议中发现的问题 剔除经确认属于重复或无效的问题 共同确定需要修改的问题及修改的程度 返工：作者根据评审报告的决议，负责解决确定的所有缺陷和问题。 跟踪：评审组长必须确保所提出的每个问题都得到了圆满解决。必须仔细检查对文档的每个修正，以确保没有注入新的错误。,正式评审流程,技术审查

11、流程,准备：评审组长（通常是项目经理）要求项目组成员提供需要考虑的特定问题并分发评审材料，确定评审重点： 需要注意的特定问题 需要满足的特殊标准或规格说明 需要审查的接口或依赖关系 评审：评审人各自审查评审材料，目的是发现错误，而非改正（通常每次评审会不超过小时）。评审组组长应在一天内写出评审报告。评审会议内容包括： 汇总个人发现的问题 加入会议中发现的问题,跟踪：作者负责解决评审报告中的所有错误及问题。评审组长检查所提出的每个问题是否都得到了解决。组长起草评审发现报告： 问题或弱项清单 小组对如何解决这些问题或弱项清单的建议 行动事项,走查流程,形式更简单。主要有两种方式： 参与者驱动法：参

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

13、与人员一起读 也可几个开发人员一起进行交叉走查 选定的进行代码走查的范围根据需求的优先级来具体确定,同行评审的结果,正常：评审专家作好了评审准备，会议正常，结果明确，不需要再次评审 延期：30%以上评审专家没有作好准备，会议无法正常进行，需要确定再次评审时间 取消：在初审阶段就发现很多问题，需要作者进行修正，然后再进行第二次同行评审,2.1.5同行评审方式的比较,2.1.6同行评审方式的选择,对于同一个工作产品，根据所处的阶段可使用不同的评审方式 工作产品刚勾画、起草时走查 完成了某一个单独的章节时技术审查 整个产品完成时正式评审,各工作产品通常采用的评审方式及参加人员：,项目总体计划 走查

14、项目经理、产品经理、需求提出者、市场或销售代表、技术负责人、质量保证工程师、高层技术管理者、过程管理者 用户需求说明书 走查 需求分析师、项目经理、架构师、设计师、系统测试工程师、质量保证经理、用户或市场代表、文档编写者、业务专家、技术支持代表 产品需求规格说明书 正式评审 需求分析师、项目经理、架构师、设计师、系统测试工程师、质量保证经理、用户或市场代表、文档编写者、业务专家、技术支持代表,项目已定义过程 正式评审 过程改进组负责人、过程改进工作组成员、管理级的过程拥有者、使用过程的实践者的代表 开发计划 技术审查 创建者、项目经理、维护者、程序员 系统测试计划 技术审查 测试工程师、程序员

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

16、求分析师（系统测试）、质量保证代表 代码 走查 程序员、设计师、单元测试工程师、维护者、需求分析师、编码标准专家 集成/验收测试记录和报告 走查 测试工程师、程序员（单元测试）或架构师（集成测试）或需求分析师（系统测试）、质量保证代表,各工作产品通常采用的评审方式及参加人员：,用户使用手册 走查 文档编写者、需求分析师、用户或市场代表、系统测试工程师、维护人员、设计师、用户教育设计师、培训师、技术支持代表 用户界面设计 技术审查 用户界面设计师、需求分析师、用户、应用领域专家、可用性或人体专家、系统测试工程师 项目总结报告 技术审查 项目经理、产品经理、需求提出者、市场或销售代表、技术负责人、

17、质量保证工程师、高层技术管理者、过程管理者,各工作产品通常采用的评审方式及参加人员：,2.1.7同行评审注意事项,一次针对产品需求的同行评审定在某日上午9:0011:00进行。之前邮件通知了与会人员，未发放评审材料。邀请了两位技术负责人，其他都是不很了解技术和评审过程与意义的管理人员，没有安排专人记录。结果可能是 会上，多数管理人员按个人喜好与想法来评价软件的优缺点，并对该软件的开发人员进行评论，提出了偏离评审会议主题的各种意见，导致会议时间延长到4小时。软件中存在的问题很少被关注。 主持人宣布会议主题后，作者简述产品需求，评审提出自己的意见。评审员小李说：“关于需要改进。”其他人也参与进来。

18、“这需要A项目组配合修改，A组负责人小张说说是否可行，打算怎么改。”小张提出自己的想法及改进方法，几个同行说出自己的想法，有时不一致，开始解释和说明该问题占用了近40分钟时间。继续2小时后，需求评审只进行了一半。会议没有得到评审结果就宣告结束，只能下次继续。会议过程中没有任何记录。,出了什么问题？,没有专门通知到个人 没有预先下发被评审的工作产品和检查单 会议焦点不在解决问题上，而是转移到了如何解决问题主持人没经验，没能很好主持和控制会场局面 没有作缺陷记录和发现工作量的记录,同行评审应遵循的原则,123准则 同行评审准备时间等于或大于开会时间 同行评审期间发现的缺陷数量应是同行评审准备期间发

19、现的缺陷数量的2倍以上 同行评审发现缺陷的效率是测试发现缺陷的3倍 同行评审需要管理层的支持，否则，即使是目标明确的开发组成员也会抵制同行评审 同行评审是结构化的过程，涉及许多参与人员的角色，选择评审专家时要注意其中的互补性 对每种类型的同行评审，应制定通用的工作产品评审检查表，必要时可适当裁减以适应特定项目的要求,评审开始前，评审人应准备好自己所关注和将提出的问题 评审的重点在于发现问题，而非解决问题 对技术人员工作的审查应由技术人员进行，管理人员别参与。但应将评审结果和解决发现问题的日期通知管理人员 评审的过程是对事不对人的，例如，可以说“这个假设是错误的”，不能说“你的假设根本不对” 成

20、功的审查要求所有参与者精力高度集中，可能会令人十分疲惫，因此每个审查阶段最好不超过2个小时。每个人每天最好只参加一个阶段审查 将评审数据输入到组织度量库中，用于监测评审效果，并管理和跟踪产品。例如： 在全过程使用同行评审，要占10%的开发工作量 每20页叙述性文档，需要40人时 每12页概要设计，需要30人时 每1000行代码，需要55人时 使用一段时间后，评价一个项目或一个组织的审查结果需要1人月,同行评审应遵循的原则,同行评审通过的准则,最小准则 工作产品已经返工和确认 主持人已经发布审查报告 基于组织的度量元或早期的审查，可以为这类工作产品设置出口准则 剩余主要缺陷数的估计是否在限定范围

21、内 剩余次要缺陷数的估计是否在限定范围内 变更数量在限值范围内（例如：IBM某部门的指南规定，变更代码应少于评审代码的5%）,2.1.8同行评审的经验共享,所有缺陷最终都应追溯到需求，因为最严重的错误是“导致程序无法满足需求”的错误 软件开发人员和管理人员首先应该尽早地和不断地进行软件质量保证活动（如需求和设计阶段的同行评审和走查等） 软件开发人员应避免检查自己的程序，利用同行评审的方式对代码进行审查 在进行各种分析和修复工作中，要充分注意修复工作所产生的影响效果和波及效果 统计表明约有的错误是在设计阶段之前注入的，且修正一个软件错误所需的费用将随着软件生存期的进展而上升 程序中的大部分错误往

22、往是在一小部分模块中发现的，遵循“二八定理” 缺陷会掩盖会加重缺陷。 遵照规范化的方法仔细复查和测试每个小程序模块，尽早排除缺陷。测试不能避免缺陷发生，只是一种补救。,2.1.9同行评审的质量,根据Watte Humphrey于1998年提出的经验数据，设计阶段同行评审工作量应占该阶段工作量的1/3或以上，代码评审工作量要占到编码和单元测试阶段的工作量1/3以上。若它们都只占到15%，此时同行评审的质量系数仅为0.5 业内通用质量准则： 设计同行评审工作量应占设计阶段总工作量的1/3以上,其质量准则为：设计文档同行评审应至少发现3个缺陷/页。经评审修改后，缺陷清除率1级100%，2级100%，

23、3级80%以上，残留缺陷密度控制在0.5个/页以下。 代码同行评审工作量应占实现阶段总工作量的1/3以上。 同行评审准备过程发现的缺陷数应是同行评审会上发现的缺陷数的2倍以上。,建议的同行评审效率,如果软件开发全过程中使用同行评审及审查，它们的总工作量要占开发工作量的10% 同行评审准备效率 需求250行（5页）/小时 概要设计200行（4页）/小时 详细设计150行（3页）/小时 源码150行（无注释）/小时 同行评审会议效率 每20页叙述性文档，需40人时 每12页概要设计，需30人时 每1000行代码，需55人时,同行评审覆盖率 对需求的同行评审覆盖率要求100% 对设计的同行评审覆盖率

24、要求100% 对系统和验收测试用例的同行评审覆盖率要求100% 对代码的同行评审覆盖率要求不少于30% 新编代码的关键部位和关键算法要进行100%的同行评审（该比例不能放宽） 非新编代码采取采样评审，采样不少于25%,2.1.10评审常见问题,根据Humphrey的经验，审查不能发挥作用的原因大致有： 最大的问题是进度紧张且管理重视不足，使得审查流于形式 实施审查的方法不当 准备不足 参与人员太多或不能胜任或有管理人员参与 一次涵盖的内容太多 在记录会议中试图修复问题 记录会议拖沓冗长 对个人进行评价,文化问题 现象1：进度驱动而非质量驱动。不重视质量，评审时间被一再挤压 现象2：管理层没有为

25、评审明确期望的目标 现象3：一些开发组人员拒绝评审他人的工作或合作 现象4：人身攻击和讽刺很普遍，作者处于防卫状态 现象5：评审中收集的数据没有在其它任何地方使用,准备问题 现象1：项目计划中没有列入大的评审工作 现象2：没有接受培训 现象3：评审人员没有提前阅读文档并提出大量问题 现象4：文档质量太差 焦点问题 现象1：没有遵循2/8原则注意评审的重点 现象2：就某个文档进行孤立评审，没有对照已有成果和标准 现象3：会议上过多讨论问题如何改正 现象4：评审与评价混淆,人员问题 现象1：评审人员选择不合理 现象2：评审人员搭配不合理 现象3：评审专家的状态 现象4：管理者要求参加他们不应参加的

26、评审 效率问题： 现象1：发现了太多的缺陷 现象2：在评审会议上重新讨论很久以前的决定，或质疑工作产品的背景 现象3：评审人员选择了不恰当的准备方法或分析技术 现象4：注意力不集中，会议跑题,效果问题 现象1：评审者总是发现同样的问题 现象2：评审的有效性无法很好度量 现象3：什么问题都完全靠会议讨论来解决 现象4：评审内容遗漏了关键部分,几个高效的同行代码评审最佳实践,一次评审量要低于 200400 行代码 每小时低于 300500 KLOC 检查率 代码评审不要超过 60-90 分钟，反之，评审代码所花的时间不得低于五分钟，就算代码只有一行 确定在评审开始之前代码开发者已经注释源代码了 为

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

28、的规模、工作量、进度、成本、质量等方面的数据和信息 规模：测试的模块数，代码行数，测试用例数，测试文档页数等 工作量与成本：计划/实际测试总工作量，用例编写/执行管理、缺陷修改/验证工作量，测试效率，返工效率，评审工作量/效率，计划/实际成本，投入人数等 进度：计划开始/结束时间，实际开始/结束时间，进度偏差，计划/实际周期，已经通过的测试用例数，已经集成的构件/功能数，关闭的问题数，用例测试通过率等 质量：各级缺陷的个数，修复/残留缺陷数，打开/关闭缺陷数，打开/关闭时间，缺陷密度，清除率等,以上常用度量元中，更看重缺陷数据的统计分析，对测试发现的缺陷，按照缺陷严重程度、注入阶段、发现阶段、

29、修复阶段、缺陷性质、所属模块等方面进行分类和统计。其中对缺陷管理更有实际价值的： 客户反馈缺陷：即漏测，可衡量测试人员的结果绩效。也可发现一些可能在未来会反馈回来的问题 模块缺陷密度：通常找到缺陷最多的地方也是潜在缺陷最多的地方 遗留缺陷数：与之前拟定的交付标准比对。被允许留下的缺陷一般也是下一阶段启动任务时开发的首要任务 测试用例有效性：可规范测试活动，提高测试用例质量。用例状态：通过、完成担有错误、失败、阻塞、忽略,测试度量信息示例,2.3管理评审(Management Review),评审包括管理评审和技术评审。同行评审属于技术评审 关注点不同： 管理评审关注计划可行性和组织的有效性 技

30、术评审关注产品的正确性，检查工作产品是否符合规定的要求 参与人员和目的不同： 管理类评审：参加者主要为管理人员，包括高级经理、项目经理、客户代表（不一定每次都参加）、下一阶段参与的人员等，还可能涉及财务核算人员，目的是解决管理问题，通常是为管理行动提供信息，要得出管理结论，如项目立项评审、里程碑评审、项目的结题审查、项目中进行的过程审查 技术类评审：一般不要求管理人员参加，目的是找出缺陷或选择技术方案，如需求评审、设计评审、代码走查、测试用例的评审等,在项目计划中已列出了管理评审要评定的内容，具体评审过程不超过半小时，真正的评审可能只有几分钟。 管理评审的前提：本阶段所涉及的所有要评审的工作产

31、品都已经作了技术评审，由项目经理和PPQA组织填写相应的评审检查表 管理评审的对象：组织的过程、项目数据、质量管理体系等 管理评审的时机：顾客要求和期望的变化，先进技术的出现，产品标准变化，组织结构及职责变化，组织运行机制变化，新技术、新工艺、新设备、新生产线采用引起资源的变化；最高管理者认为必要时,管理评审的特点： 高层次性：由管理者主持，过程管理负责人员参加，相对高层次的正式评价活动 战略性：从战略的眼光来审视包括目标在内的整个经营活动是否适宜，从战略的高度来审时度势，决策发展方向 风险性：评审的结果可能引起组织对质量方针、质量目标、质量管理体系的重大改进，而组织的外部环境具有多变性、不可

32、控性和复杂性潜伏着许多不确定性因素，因此，这种改进不能冒一定的风险,里程碑评审,全面地对项目组外部的成员展示工作产品的完成情况及进展、费用等情况，同时高级经理确定项目是否可以进入到下一阶段 目的：按照计划（项目计划中已经列出要评定的内容）评审当前项目的进展，审查下一个阶段的计划，处理特定的问题等 过程：按照项目计划，在里程碑点进行评审。参与人员包括项目经理和主要的项目相关人员，还包括项目组以外的管理决策层。在会议前解决主要问题，并审查要交付的产品。通过讨论，对评审问题达到一致，标识行动项 注意：是否全面评价了项目组的进展，是否对项目组外的相关人员展示了项目组的进展？项目计划中是否已经列出要评定

33、的内容？本里程碑阶段涉及的所有要评审的工作产品是否都已作了技术评审？,同行评审报告,同行评审报告,同行评审检查单,同行评审检查单,管理评审报告,管理评审报告,2.4 PPQA发现,PPQA：Product & Process Quality Assurance，产品过程质量保证，简称QA。按照可应用的过程描述、标准和规程客观地评价执行的过程、工作产品、服务 不仅检查工作产品的规范性和符合性，还要按照公司的标准和规范评价开发中涉及的各个过程 QA人员不仅要知道过程，还要有更多的项目管理经验、开发经验、具体的技术的经验,QA的工作,评价过程 QA要了解过程中易犯错误的关键点 观察生命周期每个阶段的

34、入口条件，检查过程中的事情是否都做了 根据CMMI，评价工作包括： 需求管理过程、项目策划过程、产品开发过程、项目监督与控制过程（可定期进行）、配置管理过程（可定期进行）、集成项目管理过程、度量与分析过程、评审、培训、组织过程定义,2.4.1 QA流程,2.4.2 QA工作内容,公司在进行CMMI改进过程中，咨询师问QA：“你认为QA在你们公司中相当于什么角色？老师？警察？医生？” QA小张：我觉得QA像警察，需要严格检查项目组的过程和产品 QA小刘：我觉得QA像这三个角色，老师可以知道项目组工作，警察可以评价开发的过程和产品，医生可以帮助项目组想办法解决问题,QA的角色,评价过程 评价产品与

35、服务 主要是评价产品与服务是否规范化，是否存在不符合问题。要求：在里程碑处以及交付用户前，评价工作产品 检查审计工作 协助项目组织审计工作的开展，并监督审计工作的执行，因为审计也是预防和发现缺陷的重要手段，是质量保证的工具 其它日常活动 帮助项目组加强对公司规范和标准的理解和使用 协助项目经理选择适合项目的过程、规程和模板 制定各种评审检查单 协助项目经理制定项目计划 协助项目经理组织评审活动 协助项目经理进行组间协调工作,对QA的要求,具备一定的知识和技能。有不断学习、提高自我的精神 具有公平公正的素质 有自信，有较强的沟通能力,2.4.3 QA发现的问题,在整个项目开发过程中，有些过程和产

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

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

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

39、行总结，从缺陷管理系统中提取本阶段的问题及处理情况，生成“QA阶段评价报告”，作为里程碑评审的参考资料。首先提交给项目经理，由项目经理或总其它资料后提供给评审人员,问题跟踪和验证。一般使用不符合问题状态跟踪表 发现问题后和责任人及项目经理沟通 将问题记载通报 和项目组协商确定解决时间和负责人 在解决时间将到时，提前提醒项目组，若正在修改，可及时了解当前的解决情况 到了计划的解决日期，验证项目组的解决情况。对不符合要求的问题，要和项目组协商，继续修改，直至验证通过。有争议的问题可直接上报给高层领导,2.4.5 QA应遵循的原则,评价开发中所有工作产品，但可以区分重点。入基线的产品、计划都必须是评

40、价重点 评价项目组裁减后的所有过程 开发过程都要检查 评价时要按照检查单和一定的抽样准则执行评价工作 在组织内要定义抽样的原则 对评价的结果，首先在组内解决，且不管是否有问题，都要通报相关人员 对发现问题的进行分类分析和汇总执行QA要有检查单 有检查就要有记录，无论是否发现问题 有问题就要跟踪直至关闭,2.4.6 QA的组织形式,让公司为难的一件事。需考虑公司实际情况 最好组建独立的QA部门，有专职的QA人员，考虑项目具体情况，合理调配QA人员，保证资源的充分利用 QA人员深入到项目组，了解项目实际情况 QA组定期召开例会，根据各自实际工作总结经验教训，将好的实践形成规范或指南，让所有QA遵守

41、和参考，以避免可能重复的过程、方法、工具的研究 若让项目组的成员兼职QA：难保公正公平，失去了QA的重要作用 若让测试人员兼职QA：在开发过程中可行，但QA也要评价验证和确认过程（包括测试）,2.4.8 QA工作的度量,投入的工作量占项目总体工总量的比例：正常情况下，QA工作量和配置管理工作量应占项目组总体工作量的5%以内 发现的不符合问题数量：过多或过少都要考虑原因。一般，过程稳定后，QA发现的不符合问题数，应等于项目组以人月数计算的工作量。 总结并提供经验数量 对公司的有关过程和标准提出改进建议数量,2.4.7 对QA的误解,QA和测试人员负责产品质量。软件出现问题是QA和测试人员的责任“

42、软件质量保证”不能保证软件的所有质量 QA就是编写文档和干零杂工作的人对QA的要求很高 QA只会站在组外品头论足、挑毛病QA从事的都是建设性的、高附加值的工作 QA把问题背后汇报给高层领导，是只知道向管理者打“小报告”的告密者要先和项目经理及负责人协商，确认后再将QA报告完全公开地发送给项目相关人员 QA就是关心开发过程是否规范，不关心产品质量，不关心技术要过程与质量并重,2.5项目组内部发现,项目经理的一个主要任务就是项目跟踪和监控，从而发现开发过程中的一些重要或隐蔽的问题。针对这些问题，首先考虑项目组内部解决，无法解决、需要领导介入帮助解决的，可通过问题报告、周报、周例会记录等各种报告形式

43、向上级反映 项目组成员在开发过程中也会发现一些问题，可反馈给项目经理，统一记录在问题报告中,2.6客户反馈,客户通过电话、邮件、访问售后服务系统等反馈来的信息，是对产品进一步升级换代和改进的重要依据，也是缺陷发现的最后一道屏障 可根据客户的反馈进行分析。如： 客户关注的主要是什么问题 客户的操作熟练程度。可考虑改进用户使用培训方面问题 客户经常发现一些在本地环境无法重现的问题。应考虑是否内部测试环境和客户实际环境有差异，或使用习惯不同 客户反馈的缺陷优势可能是新的需求。考虑改进需求分析 客户反馈的缺陷是否由于版本更新出错引起的，后期可考虑改进更新方法 测试遗漏的bug占测试人员发现的bug的百分比，据此确定测试人员的工作效果，并起到对测试人员的监督作用 针对客户的反馈进行过滤，确定是否修改及修改的优先级,小结,常用缺陷发现手段： 同行评审 测试 管理评审 PPQA发现 项目组内部发现 客户反馈 有效的同行评审发现的问题数可以占到40%左右，大的问题基本都是同行评审发现的 传统意义上的测试发现和解决的问题数一般可占到35%，退化到了第二位,