1、Quality Control/Review/1Seminar on CMM软件质量控制（华 公司CMM体系研讨会）Quality Control/Review/2Seminar on CMM目目 标标 理解CMM软件质量控制 理解软件质量控制生命周期 清楚评审和测试实施过程 清楚评审和测试的规范Quality Control/Review/3Seminar on CMM主要内容主要内容 软件质量的定义 质量控制生命周期 软件评审过程 正规检视过程 软件测试 CHECKLISTS及相关文档Quality Control/Review/4Seminar on CMM“The quality of
2、 a software system is governed by the quality of the process used to develop and evolve it”-Watts HumphreyQuality Control/Review/5Seminar on CMM软件质量软件质量 软件质量：与软件产品满足需求的能力有关的特征或特征的全体 软件质量反映了三个方面的问题:需求：软件需求是度量软件质量的基础 开发标准：定义的一些开发准则.保证开发质量 隐含的需求：如可维护性Quality Control/Review/6Seminar on CMM软件质量软件质量质量人技术流
3、程质量铁三角 人、技术、流程Quality Control/Review/7Seminar on CMM项目成功三要素项目成功三要素项目质量进度成本Quality Control/Review/8Seminar on CMM产品开发工作量分布产品开发工作量分布我们的统计数据我们的统计数据50.1%7.5%42.4%系统联调和系统测试系统联调和系统测试系统分析和总体设计系统分析和总体设计设计、实现和单元、设计、实现和单元、集成测试集成测试美国国防部经验数据美国国防部经验数据15.0%23.1%61.9%系统联调和系统测试系统联调和系统测试系统分析和总体设计系统分析和总体设计设计、实现和单元、设计
4、、实现和单元、集成测试集成测试Quality Control/Review/9Seminar on CMMCMM简介简介o Capability Maturity Modelo 评估软件过程的能力，衡量软件过程改进的尺度o 以提高软件质量为核心Quality Control/Review/10Seminar on CMMInitial(1)Repeatable(2)Defined(3)Managed(4)Optimizing(5)CMM等级等级Quality Control/Review/11Seminar on CMMCMM体系体系o CMM是一个理论框架，各不同组织可根据相应的实际情况制定
5、自己的实践。o 例如：Motorola应用研发中心的SEMIS（Softwate Engineering Management Information System）印度Infosys公司TQM（Total Quality Management）QMS（Quality Management System）Quality Control/Review/12Seminar on CMMCMM实质实质o 形成文档化的制度、规范和模板o 严格按照制度办事o 按照要求形成记录o 检查、监督和持续改善 Quality Control/Review/13Seminar on CMM质量控制质量控制生命周期生
6、命周期Quality Control/Review/14Seminar on CMMSDCodeUTRACode reviewTest dataSRS reviewSTPSDD reviewSTD/Test casesIntegrateSTITReleaseQuality Control/Review/15Seminar on CMMITPISTReleaseSIQuality Control/Review/16Seminar on CMM质量文化质量文化 凡事预则立，不预则废 言必称流程 凡事要评审 在流程中保证质量 质量是我们的自尊心Quality Control/Review/17Sem
7、inar on CMM评评 审审Quality Control/Review/18Seminar on CMM评评 审审 在产品开发的阶段点，按流程，有计划地组织一批各领域的专家，通过讨论并且得出结论，进行产品决策、方案优化、产品质量评定等工作。Quality Control/Review/19Seminar on CMM评审阶段点评审阶段点概念启动需求设计分解需求规格设计概要设计开发测试发布详细设计评审1评审2评审3Quality Control/Review/20Seminar on CMM为什么进行评审？为什么进行评审？I统计数据：每1000行源代码中大约有60个错误。2/3的错误是发生
8、在需求分析以及概要设计阶段Quality Control/Review/21Seminar on CMM为什么进行评审？为什么进行评审？SUMMARY OF IBM(B.Boehm)SURVEY0.515.05.0AnalysisDesignCodeTestImplem.1.20.2Relative cost to fix errorQuality Control/Review/22Seminar on CMM为什么进行评审？为什么进行评审？评审可以尽早发现问题 评审能更直接地面对设计，从设计中发现问题 评审可以作为一种项目跟踪的手段 Quality Control/Review/23Semi
9、nar on CMM为什么进行评审？为什么进行评审？评审可反馈信息 -对产品质量现状的反馈 -对开发过程的反馈 评审有培训、交流的作用 -项目组更加了解该项目 -提高新员工的技术能力 Quality Control/Review/24Seminar on CMM过程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、（评审耗时10天；CAD10天，投板15天，调试8天）投板1次评审介绍评审介绍 实例实例Quality Control/Review/25Seminar on CMM过程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次评审介绍评审介绍 实例实例Quality Control/Review
11、/26Seminar on CMM参加人员花费时间发现问题投板次数总共耗时项目A427.75小时11-13-7143天项目B110小时1-3-03109天结果比较结果比较Quality Control/Review/27Seminar on CMM 我设计的东西别人不懂把自己的设计当作标准。其实，当方案没有确定之前，设计者的想法不过是方案之一罢了。设计必须要有个性、有风格用个性化艺术创造的思维方式来对待团队化的产品开发，是绝对错误的。我们安排评审的目的，除了发现和解决问题之外，还需要把多方的思想汇总，从而使设计优化。三个臭皮匠，赛过一个诸葛亮，就是这个道理。请大家分析以下观点：请大家分析以下观
12、点：Quality Control/Review/28Seminar on CMMv 进行大方向决策（评审）v 尽可能早的发现、改正硬件设计、测试等开发过程中存在的错误和不足v 提高产品质量、缩短开发周期、降低开发成本v 排除产生错误放大效应现象的潜在因素评审数据不做为评估开发、测试人员水平的依据评审介绍评审介绍 评审目的评审目的Quality Control/Review/29Seminar on CMMv 评审输入 评审资料：计划、文档等v 评审输出 开发/测试文档评审意见表 开发/测试文档评审报告（含评审结论）评审过程评估报告评审介绍评审介绍 输入输入/输出输出Quality Contr
13、ol/Review/30Seminar on CMM 制定设计规范，完善质量保证规范，制定评审规范。与产品组一起，制定月度评审计划，明确评审文档的主审人。组织一二级评审级别文档的评审。指导三级评审级别文档的评审。审核评审结论，得出最终评审结论，确定重大设计方案的改动。评审角色评审角色 总体组总体组Quality Control/Review/31Seminar on CMM 确定评审级别及主审人 确定评审任务的监督QA评审角色评审角色 系统组系统组Quality Control/Review/32Seminar on CMM 根据文档计划按时完成开发文档。在评审会议前根据文档设计内容和专家意见
14、进行会议设计，制作胶片。准备评审的相关资料和评审要点说明。根据专家意见和评审意见修改或重写文档。评审角色评审角色 项目组项目组Quality Control/Review/33Seminar on CMM 组织文档评审的整个流程。填写初审结论，决定需否开评审会。组织评审会议，填写评审报告，得出文档评 审结论。评审角色评审角色 主审人主审人Quality Control/Review/34Seminar on CMM 根据文档和评审要点说明，进行文档评审，填写评审意见表，并将意见及时（在评审会前）反馈给主审人和项目组。准时参加评审会，提出有针对性、有价值的评审意见。评审角色评审角色 评审专家评审
15、专家Quality Control/Review/35Seminar on CMM 根据各项目组文档计划统计下月文档清单。跟踪项目进度，督促项目组按时提交文档。根据评审情况对评审资格人员进行评价。对评审过程进行评估，提交评审过程评估报告评审角色评审角色 QAQuality Control/Review/36Seminar on CMM正正 规规 检检 视视Quality Control/Review/37Seminar on CMM什么是正规检视？什么是正规检视？Fagan Inspections（IBM）软件开发周期中对软件产品的技术检查 正规检视贯穿于产品开发的过程中Quality Con
16、trol/Review/38Seminar on CMM在开发中的阶段在开发中的阶段检视对象阶段评审正规检视改进的检视对象阶段评审Quality Control/Review/39Seminar on CMM正规检视正规检视 目的目的 尽可能早的发现、改正开发过程中存在的错误和不足 提高产品质量、缩短开发周期、降低开发成本 排除产生错误放大效应现象的潜在因素o 正规检视不做为评估开发、测试人员水平的依据Quality Control/Review/40Seminar on CMM正规检视小组正规检视小组Quality Control/Review/41Seminar on CMM人员组成人员组
17、成 组织者（Moderator）开发者（Producer）检视者（Inspector）讲解员（Reader）记录员（Recorder）Quality Control/Review/42Seminar on CMM组织者职责组织者职责 主持、引导正规检视的运行过程，全面负责正规检视的效果 责任：组建检视小组，分配检视小组的角色，领导正规检视过程Quality Control/Review/43Seminar on CMM开发者职责开发者职责 提供相关检视资料 回答检视者的问题 修改检视过程中发现的错误Quality Control/Review/44Seminar on CMM检视者职责检视者职
18、责 产品生命周期中直接参加产品开发的人 完成检视工作，发现检视对象中存在的问题和不足Quality Control/Review/45Seminar on CMM讲解员职责讲解员职责 在介绍会议以及检视会议上讲解检视对象 引导检视小组对产品进行彻底审查Quality Control/Review/46Seminar on CMM记录员职责记录员职责 详细准确地记录在检视会议上已确认的问题 错误的出处，错误的简单描述，错误的分类，和发现错误的检视者Quality Control/Review/47Seminar on CMM检视小组成员素质检视小组成员素质 有对产品质量负责的精神 有良好的团队合
19、作精神，不人身攻击 以评估检视对象、发现问题为目的，不去评价开发者的能力 能将发现的问题正确、清晰地予以说明 检视过程中，坚持已建立的标准及规范 在技术问题上，能够实事求是，一丝不苟Quality Control/Review/48Seminar on CMM正规检视过程正规检视过程Quality Control/Review/49Seminar on CMM正规检视正规检视 阶段划分阶段划分 计 划 介绍会议（可选阶段）会议准备 检视会议 第3小时会议（可选阶段）修改错误 问题跟踪Quality Control/Review/50Seminar on CMM正规检视正规检视 方法方法 各检视
20、者单独检视，寻找检视对象的错误 检视会议中对各检视者发现的错误进行确认 记录经过确认的错误 将正规检视所得的错误列表提交给开发者 跟踪确认提交给开发者的错误得到正确修改.Quality Control/Review/51Seminar on CMM正规检视正规检视 进入标准进入标准 检视对象为开发过程中的半产品，例如没有经过评审的文档、原理图等 检视对象具备一定的完整性 检视对象已经经过开发人员的充分自检 具备合格的检视人员.Quality Control/Review/52Seminar on CMM正规检视正规检视 结束标准结束标准 检视发现的所有主要问题已经被正确修改 检视过程数据已反馈
21、给质量部门，检视过程得到QA认可，检视过程数据已记录Quality Control/Review/53Seminar on CMM正规检视正规检视 计划阶段计划阶段 计划阶段工作由组织者完成 确定检视对象是否满足正规检视的进入标准 制定检视计划 成立检视小组、确定人员职责、分配检视任务 安排正规检视会议时间，预定相关资源 准备并发放正规检视的资料 确定是否举行介绍会议 组织者将本阶段过程数据记录在检视综合报告中Quality Control/Review/54Seminar on CMM正规检视正规检视 计划阶段计划阶段 输入 正规检视对象 正规检视相关资料 输出 正规检视通知单 资料袋Qua
22、lity Control/Review/55Seminar on CMM正规检视正规检视 介绍会议（可选）介绍会议（可选）讲解员介绍检视对象的背景信息 确定检视者的任务 组织者将本阶段过程数据记录在检视综合报告中Quality Control/Review/56Seminar on CMM正规检视正规检视 会议准备阶段会议准备阶段 检视者参照查检表，单独审查检视对象 检视者将发现的错误、修改建议、花费时间记录到正规检视问题登记表中 组织者汇总检视者提交的检视问题，确定是否可以举行检视会议 组织者将本阶段过程数据记录在检视综合报告中Quality Control/Review/57Seminar
23、 on CMM正规检视正规检视 会议准备阶段会议准备阶段 输入 资料袋 输出 正规检视问题登记表Quality Control/Review/58Seminar on CMM正规检视正规检视 检视会议阶段检视会议阶段 确认并分类在会议准备阶段发现的问题 将确认的问题记录在正规检视审查列表中 对检视会上无法确认的问题提出处理意见 确定是否需要重新做正规检视 确定是否需要进行第3小时会议Quality Control/Review/59Seminar on CMM检视会议阶段（续）检视会议阶段（续）估计修改错误的时间和需要的人力、时间，对无法确认的问题的处理也要进行估计 确定问题修改跟踪责任人 组
24、织者将本阶段过程数据记录在检视综合报告中Quality Control/Review/60Seminar on CMM正规检视正规检视 检视会议阶段检视会议阶段 输入 资料袋 空白正规检视审查列表 经汇总的问题登记表 输出 正规检视审查列表 有详细问题标注的检视对象Quality Control/Review/61Seminar on CMM正规检视正规检视 检视会议阶段检视会议阶段 检视只针对检视对象，不评估开发者的能力 发现、确认问题是本阶段的唯一目的，而不要关心其他方面问题，例如问题的解决方法等 所有检视者均应参加会议，在即将召开检视会议之前，不允许替换检视者Quality Contro
25、l/Review/62Seminar on CMM正规检视正规检视 修改错误阶段修改错误阶段 开发者对本次正规检视发现的问题进行处理 处理所有主要问题 根据实际情况，考虑其他非主要问题的处理方式 组织者将本阶段过程数据记录在检视综合报告中Quality Control/Review/63Seminar on CMM正规检视正规检视 修改错误阶段修改错误阶段 输入 正规检视审查列表 已标注问题的检视对象 第3小时会议中讨论所得的问题解决方法、途径 输出 主要错误已全部修改的检视对象 本阶段过程数据记录Quality Control/Review/64Seminar on CMM正规检视正规检视
26、修改错误阶段修改错误阶段 要求处理所有主要的问题 其他一般问题根据实际情况进行处理 修改错误的时间建议为5-20小时 严格按计划完成修改工作Quality Control/Review/65Seminar on CMM正规检视正规检视 问题跟踪阶段问题跟踪阶段 确认所有主要问题已修改 注意在修改过程中不引出新问题 妥善处理无法确认的问题 记录本阶段过程数据 完成正规检视综合报告，并提交给给项目经理、开发者、质量管理部门（QA）归档员完成相关数据的归档 如有必要，可以召开问题修改确认会议Quality Control/Review/66Seminar on CMM正规检视正规检视 问题跟踪阶段问
27、题跟踪阶段输入 错误已经改正的检视对象 开发者已填写的正规检视审查列表输出 通过了正规检视的检视对象 组织者已确认的正规检视审查列表 组织者已妥善处理了无法确认问题 正规检视综合报告Quality Control/Review/67Seminar on CMM正规检视正规检视 小组构成准则小组构成准则 检视小组规模不大，一般由3 7 人组成 小组成员的本职工作应与检视对象有一定的关系，例如相关的开发、测试人员或用户等 每个小组成员都有自己确定的任务和职责 检视小组成员均为兼职人员Quality Control/Review/68Seminar on CMM正规检视正规检视 检视对象准则检视对象
28、准则 正规检视对象的规模不宜过大 以软件为例，检视对象规模推荐值 审查对象类型 推荐值可调整范围 概要设计文档30 页20 -40 页 详细设计文档35 页25 -45 页 程 序 代 码500 行 400-600行 程序代码以每个检视人员的工作量在 200-250 行为基准，具体检视时可根据检视人员的数量、检视对象的类型进行小范围调整Quality Control/Review/69Seminar on CMM正规检视正规检视 时间准则时间准则 介绍会议：30 60 分钟 准备阶段：3 个工作日以内 检视者应在检视会议进行4小时前将问题登记表提交给组织者 检视会议：2小时以内 修改问题阶段：
29、5 20 小时 检视全过程：不超过12个工作日Quality Control/Review/70Seminar on CMMCHECKLISTSQuality Control/Review/71Seminar on CMM软件测试软件测试Quality Control/Review/72Seminar on CMM主要内容主要内容 测试的概念 测试的分类及各阶段方法 测试文档模板 总结Quality Control/Review/73Seminar on CMM软件测试软件测试 测试，并不是一个行为和方法，和设计、编码没有本质区别，是软件开发生命周期中一个不可缺少的环节 缺少了哪个阶段，都要为
30、之付出代价Quality Control/Review/74Seminar on CMM软件测试的发展软件测试的发展 测试与调试没有什么不同。测试是为了证明软件能工作。测试是为了证明软件不能工作。测试不是为了证明什么，而是将可察觉的软件风险降低到一个可接受的下限。测试不是作为具体的行为而存在。而是为了以尽可能少的测试投入达到尽可能低软件风险的一种自觉的心理。Quality Control/Review/75Seminar on CMM测试的阶段测试的阶段 单元测试 集成测试 系统测试Quality Control/Review/76Seminar on CMM测试的阶段测试的阶段 单元测试 集
31、成测试 系统测试Quality Control/Review/77Seminar on CMM单元测试单元测试Quality Control/Review/78Seminar on CMM单元测试定义单元测试定义 说法不一但内涵基本一致：对软件基本组成单元进行的测试。单元测试是后续的集成测试、系统测试等测试活动的基础。Quality Control/Review/79Seminar on CMM单元的理解单元的理解 一个单元一般是一个函数，或类的一个方法 单元的代码量一般在200行以下(推荐小于100行)单元的功能、输入和输出非常明确 单元是基本上不能再细分的一段程序 设计阶段就要保证代码的可
32、测性Quality Control/Review/80Seminar on CMM单元测试在单元测试在V模型中模型中需求规格概要设计详细设计编码单元测试集成测试系统测试单元测试设计Quality Control/Review/81Seminar on CMM单元测试目的单元测试目的 单元测试是研发流程中不可缺少、其它测试无法代替的软件开发阶段 保证构成系统的每一个单元（通常是一个函数）功能的正确实现 将错误消灭在最开始（节省时间、人力和物力）可以发现设计和实现中的错误Quality Control/Review/82Seminar on CMM单元测试关注点单元测试关注点 对正常输入和异常输入
33、的正确处理 依照设计得到正确的输出 内部逻辑的正确性 对局部和全局数据的正确操作 对异常发生时的正确处理 单元测试的覆盖率Quality Control/Review/83Seminar on CMM 单元测试内容单元测试内容o 单元功能 测试单元是否实现了详细设计中所定义的功能要求o 单元的内部结构 对局部数据结构的检查保证临时存储的数据在算法执行的整个过程中都能维持其完整性 对边界条件的测试保证模块在极限情况下仍能正确的执行 在控制结构中的所有独立路径都要走遍，以保证模块中所有语句都能至少执行一次 对所有的错误处理路径都要测试Quality Control/Review/84Seminar
34、 on CMM单元测试例的设计方法单元测试例的设计方法 桩和驱动概念 设计策略 总体原则 测试例模板 测试例样例Quality Control/Review/85Seminar on CMM 桩函数和驱动函数桩函数和驱动函数 桩（Stub）函数：在开发或测试阶段用来仿真一个实际的部件或对象行为的哑(Dumb)部件 驱动（Driver）：在开发或测试阶段用来仿真对一个部件进行数据输入、输出获取和调度控制的部件Quality Control/Review/86Seminar on CMM 单元测试总体原则单元测试总体原则 单元测试用例的设计根据是软件详细设计文档 单元测试用例设计在编码之前完成 先
35、用“黑盒”方法测试功能，后用“白盒”方法跟踪函数内部逻辑Quality Control/Review/87Seminar on CMM单元测试误区单元测试误区 一切为了覆盖率 依据代码进行测试，而不是规格和设计 没有设计测试用例，直接开始 对设计和代码没有了解的人执行单元测试Quality Control/Review/88Seminar on CMM 单元测试例模板单元测试例模板测试例编号项目代号_UT_模块名_001测试标题描述测试某个函数测试预置条件描述前提条件测试输入/过程描述具体输入,测试过程测试级别高、中、低预期结果描述预期的结果Quality Control/Review/89S
36、eminar on CMM 单元测试用例单元测试用例 测试例的输入从如下方面考虑：函数的输入参数函数使用的全局变量STUB的返回值和输出值 测试例的预期结果从如下方面考虑：函数的输出参数函数修改了的全局变量函数的返回值函数向屏幕的输出信息 内存的申请和释放情况函数向外发送消息Quality Control/Review/90Seminar on CMM 单元测试入口条件单元测试入口条件 单元测试计划得到批准 代码得到批准 代码纳入配置管理Quality Control/Review/91Seminar on CMM 单元测试出口条件单元测试出口条件 全部单元测试例通过 单元测试覆盖率达到指定要
37、求(语句覆盖率为100)测试记录产生 错误报告产生，相应错误消除 最终的测试状态报告通过项目经理的批准以及产品经理的签发Quality Control/Review/92Seminar on CMM 单元测试工具单元测试工具 PC-Lint：编译出现的各种错误检查工具(公司规定必须使用)GCT：Unix使用的覆盖率度量工具 TrueCoverage、Coverage：Windows下覆盖率度量工具Quality Control/Review/93Seminar on CMM集成测试集成测试Quality Control/Review/94Seminar on CMM 集成测试集成测试 集成测试
38、是把若干经过单元测试的模块组装在一起而进行的功能性测试，侧重于功能测试Quality Control/Review/95Seminar on CMM 集成测试在模型中集成测试在模型中需求规格概要设计详细设计编码集成测试单元测试系统测试集成测试设计Quality Control/Review/96Seminar on CMM 对象、依据、目的对象、依据、目的 对象：程序间调用关系和接口数据 依据：概要设计说明书和详细设计说明书 目的：找出与软件设计相关的程序结构，模块调用关系，模块间接口Quality Control/Review/97Seminar on CMM 测试方法测试方法 灰盒测试 对
39、象：程序间调用关系和接口数据 依据：概要设计说明书和详细设计说明书 目的：找出与软件设计相关的程序结构，模块调用关系，模块间接口Quality Control/Review/98Seminar on CMM系统测试系统测试Quality Control/Review/99Seminar on CMM系统测试定义 针对软件产品系统进行的测试，主要目的是验证软件是否满足了系统需求规格的定义 测试对象：系统，包括软件，硬件，外设及接口 依据：需求规格说明书Quality Control/Review/100Seminar on CMM系统测试标准过程 测试过程测试计划测试设计测试实现测试执行测试过程
40、体现了测试设计和实现的分离Quality Control/Review/101Seminar on CMM系统测试标准过程（续）系统测试计划阶段系统测试设计阶段系统测试实现阶段系统测试执行阶段系统测试计划系统测试方案系统测试用例系统测试工具设计实现系统测试报告系统测试总结报告Quality Control/Review/102Seminar on CMM系统测试计划阶段 入口准则：软件项目计划的开发计划完成，软件测试计划完成 输入：软件开发计划、软件测试计划 输出：软件系统测试计划 出口准则：通过软件系统测试计划的评审Quality Control/Review/103Seminar on C
41、MM系统测试设计阶段 入口准则：需求分析完成，建立需求基线 输入：需求规格说明书、系统测试计划 输出：系统测试方案 出口准则：通过软件系统测试方案的评审Quality Control/Review/104Seminar on CMM系统测试实现阶段 入口准则：软件系统测试方案完成 输入：系统规格说明书、系统测试计划、软件概要设计说明书、软件系统测试方案 输出：软件系统测试用例 出口准则：软件系统测试用例通过评审 Quality Control/Review/105Seminar on CMM系统测试执行阶段 入口准则：集成测试完成 输入：软件系统测试计划、方案及测试用例 输出：软件系统预测试报告及转系统测试评审表，系统测试报告及评审表 出口准则：通过系统测试计划中的测试通过准则，通过系统测试报告评审 Quality Control/Review/106Seminar on CMM如何做好系统测试 参与系统测试的时间 软件需求规格 用户需求 好的流程+好的推行 Quality Control/Review/107Seminar on CMM测试文档测试文档
