软件质量控制（华 公司CMM体系研讨会） .ppt

软件质量控制,CMM体系研讨会,评审与测试实施,目 标,理解CMM软件质量控制理解软件质量控制生命周期清楚评审和测试实施过程清楚评审和测试的规范,主要内容,软件质量的定义质量控制生命周期软件评审过程正规检视过程软件测试CHECKLISTS及相关文档,“The quality of a software system is governed by the quality of the process used to develop and evolve it”-Watts Humphrey,软件质量,软件质量：与软件产品满足需求的能力有关的特征或特征的全体软件质量反映了三个方面的问题:需求：软件需求是度量软件质量的基础开发标准：定义的一些开发准则.保证开发质量隐含的需求：如可维护性,软件质量,质量,人,技术,流程,质量铁三角 人、技术、流程,项目成功三要素,项目,质量,进度,成本,产品开发工作量分布,CMM简介,Capability Maturity Model评估软件过程的能力，衡量软件过程改进的尺度以提高软件质量为核心,Initial(1),Repeatable(2),Defined(3),Managed(4),Optimizing(5),CMM等级,CMM体系,CMM是一个理论框架，各不同组织可根据相应的实际情况制定自己的实践。例如：Motorola应用研发中心的SEMIS（Softwate Engineering Management Information System）印度Infosys公司TQM（Total Quality Management）QMS（Quality Management System）,CMM实质,形成文档化的制度、规范和模板严格按照制度办事按照要求形成记录检查、监督和持续改善,质量控制,生命周期,SD,Code,UT,RA,Code reviewTest data,SRS reviewSTP,SDD reviewSTD/Test cases,Integrate,ST,IT,Release,Starts V Model,QCLC,SDLC,IT,PI,ST,Release,SI,Balloon Model,质量文化,凡事预则立，不预则废言必称流程凡事要评审在流程中保证质量 质量是我们的自尊心,评 审,评 审,在产品开发的阶段点，按流程，有计划地组织一批各领域的专家，通过讨论并且得出结论，进行产品决策、方案优化、产品质量评定等工作。,评审阶段点,概念启动,需求设计,分解需求,规格设计,概要设计,开发,测试,发布,详细设计,评审1,评审2,评审3,为什么进行评审？,I统计数据：每1000行源代码中大约有60个错误。2/3的错误是发生在需求分析以及概要设计阶段,为什么进行评审？,SUMMARY OF IBM(B.Boehm)SURVEY,0.5,15.0,5.0,Analysis,Design,Code,Test,Implem.,1.2,0.2,Relative cost to fix error,为什么进行评审？,评审可以尽早发现问题评审能更直接地面对设计，从设计中发现问题评审可以作为一种项目跟踪的手段,为什么进行评审？,评审可反馈信息-对产品质量现状的反馈-对开发过程的反馈评审有培训、交流的作用-项目组更加了解该项目-提高新员工的技术能力,过程A：参加人员：4（不包括开发者）检视规模：12页 发现错误数：严重 11个 一般 13 个 建议 7 个 时间跨度：5.11-5.15（检视会议）-5.20（问题跟踪）实际花费时间：27.75 小时 人均时间：6.94 小时人均问题数：11/3=3.67 单问题耗时：6.94/3.67=1.89结果：从设计完成到投板调试成功共43天（评审耗时10天；CAD10天，投板15天，调试8天）投板1次,评审介绍 实例,过程B：参加人员：1进行自检（开发者）检视规模：12页 发现错误数：严重 1个 一般 3 个时间跨度：5.12-5.13 5.20（问题修改）实际花费时间：10 小时 人均时间：10 小时人均问题数：4/1=4 单问题耗时：2.5结果：从设计完成到投板调试成功共109天（自检：2天，修改：4天，CAD（3次）：20天，投板（3次）：45天，调试：35天）投板3次,评审介绍 实例,结果比较,我设计的东西别人不懂把自己的设计当作标准。其实，当方案没有确定之前，设计者的想法不过是方案之一罢了。设计必须要有个性、有风格用个性化艺术创造的思维方式来对待团队化的产品开发，是绝对错误的。我们安排评审的目的，除了发现和解决问题之外，还需要把多方的思想汇总，从而使设计优化。三个臭皮匠，赛过一个诸葛亮，就是这个道理。,请大家分析以下观点：,进行大方向决策（评审）尽可能早的发现、改正硬件设计、测试等开发过程中存在的错误和不足 提高产品质量、缩短开发周期、降低开发成本 排除产生错误放大效应现象的潜在因素评审数据不做为评估开发、测试人员水平的依据,评审介绍 评审目的,评审输入 评审资料：计划、文档等 评审输出 开发/测试文档评审意见表 开发/测试文档评审报告（含评审结论）评审过程评估报告,评审介绍 输入/输出,制定设计规范，完善质量保证规范，制定评审规范。与产品组一起，制定月度评审计划，明确评审文档的主审人。组织一二级评审级别文档的评审。指导三级评审级别文档的评审。审核评审结论，得出最终评审结论，确定重大设计方案的改动。,评审角色 总体组,确定评审级别及主审人 确定评审任务的监督QA,评审角色 系统组,根据文档计划按时完成开发文档。在评审会议前根据文档设计内容和专家意见进行会议设计，制作胶片。准备评审的相关资料和评审要点说明。根据专家意见和评审意见修改或重写文档。,评审角色 项目组,组织文档评审的整个流程。填写初审结论，决定需否开评审会。组织评审会议，填写评审报告，得出文档评 审结论。,评审角色 主审人,根据文档和评审要点说明，进行文档评审，填写评审意见表，并将意见及时（在评审会前）反馈给主审人和项目组。准时参加评审会，提出有针对性、有价值的评审意见。,评审角色 评审专家,根据各项目组文档计划统计下月文档清单。跟踪项目进度，督促项目组按时提交文档。根据评审情况对评审资格人员进行评价。对评审过程进行评估，提交评审过程评估报告,评审角色 QA,正 规 检 视,什么是正规检视？,Fagan Inspections（IBM）软件开发周期中对软件产品的技术检查正规检视贯穿于产品开发的过程中,在开发中的阶段,正规检视 目的,尽可能早的发现、改正开发过程中存在的错误和不足提高产品质量、缩短开发周期、降低开发成本排除产生错误放大效应现象的潜在因素正规检视不做为评估开发、测试人员水平的依据,正规检视小组,人员组成,组织者（Moderator）开发者（Producer）检视者（Inspector）讲解员（Reader）记录员（Recorder）,组织者职责,主持、引导正规检视的运行过程，全面负责正规检视的效果责任：组建检视小组，分配检视小组的角色，领导正规检视过程,开发者职责,提供相关检视资料回答检视者的问题修改检视过程中发现的错误,检视者职责,产品生命周期中直接参加产品开发的人完成检视工作，发现检视对象中存在的问题和不足,讲解员职责,在介绍会议以及检视会议上讲解检视对象引导检视小组对产品进行彻底审查,记录员职责,详细准确地记录在检视会议上已确认的问题错误的出处，错误的简单描述，错误的分类，和发现错误的检视者,检视小组成员素质,有对产品质量负责的精神有良好的团队合作精神，不人身攻击以评估检视对象、发现问题为目的，不去评价开发者的能力能将发现的问题正确、清晰地予以说明检视过程中，坚持已建立的标准及规范在技术问题上，能够实事求是，一丝不苟,正规检视过程,正规检视 阶段划分,计 划介绍会议（可选阶段）会议准备检视会议第3小时会议（可选阶段）修改错误问题跟踪,正规检视 方法,各检视者单独检视，寻找检视对象的错误检视会议中对各检视者发现的错误进行确认记录经过确认的错误将正规检视所得的错误列表提交给开发者跟踪确认提交给开发者的错误得到正确修改.,正规检视 进入标准,检视对象为开发过程中的半产品，例如没有经过评审的文档、原理图等检视对象具备一定的完整性检视对象已经经过开发人员的充分自检具备合格的检视人员.,正规检视 结束标准,检视发现的所有主要问题已经被正确修改检视过程数据已反馈给质量部门，检视过程得到QA认可，检视过程数据已记录,正规检视 计划阶段,计划阶段工作由组织者完成确定检视对象是否满足正规检视的进入标准制定检视计划成立检视小组、确定人员职责、分配检视任务安排正规检视会议时间，预定相关资源准备并发放正规检视的资料确定是否举行介绍会议组织者将本阶段过程数据记录在检视综合报告中,正规检视 计划阶段,输入 正规检视对象 正规检视相关资料输出 正规检视通知单 资料袋,正规检视 介绍会议（可选）,讲解员介绍检视对象的背景信息确定检视者的任务组织者将本阶段过程数据记录在检视综合报告中,正规检视 会议准备阶段,检视者参照查检表，单独审查检视对象检视者将发现的错误、修改建议、花费时间记录到正规检视问题登记表中组织者汇总检视者提交的检视问题，确定是否可以举行检视会议组织者将本阶段过程数据记录在检视综合报告中,正规检视 会议准备阶段,输入 资料袋输出 正规检视问题登记表,正规检视 检视会议阶段,确认并分类在会议准备阶段发现的问题将确认的问题记录在正规检视审查列表中对检视会上无法确认的问题提出处理意见确定是否需要重新做正规检视确定是否需要进行第3小时会议,检视会议阶段（续）,估计修改错误的时间和需要的人力、时间，对无法确认的问题的处理也要进行估计确定问题修改跟踪责任人组织者将本阶段过程数据记录在检视综合报告中,正规检视 检视会议阶段,输入 资料袋 空白正规检视审查列表 经汇总的问题登记表输出 正规检视审查列表 有详细问题标注的检视对象,正规检视 检视会议阶段,检视只针对检视对象，不评估开发者的能力发现、确认问题是本阶段的唯一目的，而不要关心其他方面问题，例如问题的解决方法等所有检视者均应参加会议，在即将召开检视会议之前，不允许替换检视者,正规检视 修改错误阶段,开发者对本次正规检视发现的问题进行处理 处理所有主要问题 根据实际情况，考虑其他非主要问题的处理方式组织者将本阶段过程数据记录在检视综合报告中,正规检视 修改错误阶段,输入 正规检视审查列表 已标注问题的检视对象 第3小时会议中讨论所得的问题解决方法、途径输出 主要错误已全部修改的检视对象 本阶段过程数据记录,正规检视 修改错误阶段,要求处理所有主要的问题其他一般问题根据实际情况进行处理修改错误的时间建议为5-20小时严格按计划完成修改工作,正规检视 问题跟踪阶段,确认所有主要问题已修改注意在修改过程中不引出新问题妥善处理无法确认的问题记录本阶段过程数据完成正规检视综合报告，并提交给给项目经理、开发者、质量管理部门（QA）归档员完成相关数据的归档如有必要，可以召开问题修改确认会议,正规检视 问题跟踪阶段,输入错误已经改正的检视对象开发者已填写的正规检视审查列表输出通过了正规检视的检视对象组织者已确认的正规检视审查列表组织者已妥善处理了无法确认问题正规检视综合报告,正规检视 小组构成准则,检视小组规模不大，一般由3 7 人组成小组成员的本职工作应与检视对象有一定的关系，例如相关的开发、测试人员或用户等每个小组成员都有自己确定的任务和职责检视小组成员均为兼职人员,正规检视 检视对象准则,正规检视对象的规模不宜过大以软件为例，检视对象规模推荐值 审查对象类型 推荐值可调整范围 概要设计文档30 页20-40 页 详细设计文档35 页25-45 页 程 序 代 码500 行 400-600行程序代码以每个检视人员的工作量在 200-250 行为基准，具体检视时可根据检视人员的数量、检视对象的类型进行小范围调整,正规检视 时间准则,介绍会议：30 60 分钟准备阶段：3 个工作日以内检视者应在检视会议进行4小时前将问题登记表提交给组织者检视会议：2小时以内修改问题阶段：5 20 小时检视全过程：不超过12个工作日,CHECKLISTS,软件测试,主要内容,测试的概念测试的分类及各阶段方法测试文档模板总结,软件测试,测试，并不是一个行为和方法，和设计、编码没有本质区别，是软件开发生命周期中一个不可缺少的环节缺少了哪个阶段，都要为之付出代价,软件测试的发展,测试与调试没有什么不同。测试是为了证明软件能工作。测试是为了证明软件不能工作。测试不是为了证明什么，而是将可察觉的软件风险降低到一个可接受的下限。测试不是作为具体的行为而存在。而是为了以尽可能少的测试投入达到尽可能低软件风险的一种自觉的心理。,测试的阶段,单元测试集成测试系统测试,测试的阶段,单元测试集成测试系统测试,单元测试,单元测试定义,说法不一但内涵基本一致：对软件基本组成单元进行的测试。单元测试是后续的集成测试、系统测试等测试活动的基础。,单元的理解,一个单元一般是一个函数，或类的一个方法单元的代码量一般在200行以下(推荐小于100行)单元的功能、输入和输出非常明确单元是基本上不能再细分的一段程序设计阶段就要保证代码的可测性,单元测试在V模型中,单元测试目的,单元测试是研发流程中不可缺少、其它测试无法代替的软件开发阶段保证构成系统的每一个单元（通常是一个函数）功能的正确实现将错误消灭在最开始（节省时间、人力和物力）可以发现设计和实现中的错误,单元测试关注点,对正常输入和异常输入的正确处理依照设计得到正确的输出内部逻辑的正确性对局部和全局数据的正确操作对异常发生时的正确处理单元测试的覆盖率,单元测试内容,单元功能 测试单元是否实现了详细设计中所定义的功能要求单元的内部结构对局部数据结构的检查保证临时存储的数据在算法执行的整个过程中都能维持其完整性对边界条件的测试保证模块在极限情况下仍能正确的执行在控制结构中的所有独立路径都要走遍，以保证模块中所有语句都能至少执行一次对所有的错误处理路径都要测试,单元测试例的设计方法,桩和驱动概念设计策略总体原则测试例模板测试例样例,桩函数和驱动函数,桩（Stub）函数：在开发或测试阶段用来仿真一个实际的部件或对象行为的哑(Dumb)部件驱动（Driver）：在开发或测试阶段用来仿真对一个部件进行数据输入、输出获取和调度控制的部件,单元测试总体原则,单元测试用例的设计根据是软件详细设计文档 单元测试用例设计在编码之前完成 先用“黑盒”方法测试功能，后用“白盒”方法跟踪函数内部逻辑,单元测试误区,一切为了覆盖率依据代码进行测试，而不是规格和设计没有设计测试用例，直接开始对设计和代码没有了解的人执行单元测试,单元测试例模板,单元测试用例,测试例的输入从如下方面考虑：函数的输入参数函数使用的全局变量STUB的返回值和输出值测试例的预期结果从如下方面考虑：函数的输出参数函数修改了的全局变量函数的返回值函数向屏幕的输出信息 内存的申请和释放情况函数向外发送消息,单元测试入口条件,单元测试计划得到批准代码得到批准代码纳入配置管理,单元测试出口条件,全部单元测试例通过单元测试覆盖率达到指定要求(语句覆盖率为100)测试记录产生错误报告产生，相应错误消除最终的测试状态报告通过项目经理的批准以及产品经理的签发,单元测试工具,PC-Lint：编译出现的各种错误检查工具(公司规定必须使用)GCT：Unix使用的覆盖率度量工具TrueCoverage、Coverage：Windows下覆盖率度量工具,集成测试,集成测试,集成测试是把若干经过单元测试的模块组装在一起而进行的功能性测试，侧重于功能测试,集成测试在模型中,对象、依据、目的,对象：程序间调用关系和接口数据依据：概要设计说明书和详细设计说明书目的：找出与软件设计相关的程序结构，模块调用关系，模块间接口,测试方法,灰盒测试对象：程序间调用关系和接口数据依据：概要设计说明书和详细设计说明书目的：找出与软件设计相关的程序结构，模块调用关系，模块间接口,系统测试,系统测试定义,针对软件产品系统进行的测试，主要目的是验证软件是否满足了系统需求规格的定义测试对象：系统，包括软件，硬件，外设及接口依据：需求规格说明书,系统测试标准过程,测试过程,测试计划,测试设计,测试实现,测试执行,测试过程体现了测试设计和实现的分离,系统测试标准过程（续）,系统测试计划阶段,系统测试设计阶段,系统测试实现阶段,系统测试执行阶段,系统测试计划,系统测试方案,系统测试用例系统测试工具设计实现,系统测试报告系统测试总结报告,系统测试计划阶段,入口准则：软件项目计划的开发计划完成，软件测试计划完成输入：软件开发计划、软件测试计划输出：软件系统测试计划出口准则：通过软件系统测试计划的评审,系统测试设计阶段,入口准则：需求分析完成，建立需求基线输入：需求规格说明书、系统测试计划输出：系统测试方案出口准则：通过软件系统测试方案的评审,系统测试实现阶段,入口准则：软件系统测试方案完成输入：系统规格说明书、系统测试计划、软件概要设计说明书、软件系统测试方案输出：软件系统测试用例出口准则：软件系统测试用例通过评审,系统测试执行阶段,入口准则：集成测试完成输入：软件系统测试计划、方案及测试用例输出：软件系统预测试报告及转系统测试评审表，系统测试报告及评审表出口准则：通过系统测试计划中的测试通过准则，通过系统测试报告评审,如何做好系统测试,参与系统测试的时间软件需求规格用户需求好的流程+好的推行,测试文档,