,杜庆峰 du_cloudsina.com,软件测试和质量保证 质量保证部分,第一部分 软件质量保证 本部分讲解的主要内容有：软件质量保证体系介绍；CMM和ISO9000介绍；一个具体的SQA计划；一个具体的正规评审过程实践介绍。 软件质量保证的概念： 仅仅把软件质量的重要性挂在口头上是不够的，必须： 明确地定义软件质量的含义； 创建一组活动，这些活动保证软件工程过程中的每个工作产品具有高质量 ； 对每个软件项目完成质量保证活动； 使用度量以改善你的软件过程并最终改善软件产品的质量。 SQA包含： 1）一种质量管理方法 2）有效的软件工程技术（方法和工具）3）在整个软件工程过程中采用正式的技术评审 4）一种多层次的测试策略 5）对软件代码、文档和数据及其修改的控制 6）保证软件开发适时遵循开发标准 7） 度量和报告机制。,第一节 软件质量保证体系 1.1 质量的几个概念 差异控制：差异控制是质量控制的核心，控制差异是获得高质量产品的关键。我们应该努力控制每一个不同的项目，减少完成项目预计需要的资源和实际使用的资源之间的差异。 质量的定义：某一事物的特征或属性。（设计质量和符合质量）。 设计质量：设计者为一件产品规定的特征。 符合质量：在实现过程中符合设计规约的程度。 在软件开发时，设计质量包括软件的需求规约、概要设计和详细设计，符合质量主要关注实现问题。 1.2 质量控制 等同于差异控制，是为了保证每一件工作产品都满足需求而在整个开发周期中进行的一系列审查、评审和测试。质量控制在创建工作产品的过程中包含一个反馈循环，度量和反馈相结合，使我们不断的调整开发过程，达到控制质量的目的。,1.3 质量成本 定义： 质量成本,预防成本,鉴定成本,故障成本,改正一个错误的质量成本图,1,10,100,1000,需求分析,设计,编码,开发测试,系统测试,实际操作,1倍,3-6倍,10倍,15-40倍,30-70倍,40-1000倍,：质量计划、FTR、测试设备、培训,：过程内和过程间的审查、设备校准、测试,：内部故障成本包括反工、修复、故障分析 外部故障成本包括解决客户抱怨、退换产品、求助电话支持、保修工作。,第二节 质量运动 全面质量管理(TQM),1.kaizen,2.Atarimae hinshitsu,3.kansei,关注软件过程,4.Miryokuteki hinshitsu,关注产品及其拓展,第三节 软件质量保证 软件质量保证应关注三个方面： 1.软件需求的符合程度 2.软件开发准则的遵循程度 3.隐含需求的满足程度 3.1 软件质量保证的背景 软件质量保证的标准20世纪70年代美国军方软件的合同中其定义为：是为了保证软件高质量而必需执行的“有计划的和系统化的行动模式”。 SQA在软件质量保证中的角色：软件工程师、项目管理者、客户、销售人员和SQA小组成员。 3.2 SQA的活动 其活动由各种任务构成，并与两种不同的参与者相关，即工程师和SQA team。SQA组负责SQA的计划、监督、记录、分析及报告。活动内容： 为项目准备SQA计划。（计划内容） 参与项目的软件过程描述的开发。,评审各项软件工程活动、对其是否符合定义好的软件过程进行核实。 审计指定的软件工作产品。 确保软件工作产品中的偏差已经记录在案并根据预定规程进行处理。 记录所有不符合要求的部分并报告高级管理者。 收集分析软件度量信息。 负责软件的配置管理（可能有专门的SCM小组）。 第四节 软件评审 软件评审的一般描述： 评审的类型,非正式的会议评审,介绍式的评审,正式的技术评审（FTR)（有时称walkthrough or inspection等）,4.1 软件缺陷对成本的影响 4.2 缺陷的放大和消除,缺陷放大模型,来自以 前步骤 的错误,通过的错误,放大的错误1：x,新产生的错误,错误检 测有效 性百分比,传给下 一个步 骤的错误,开发步骤,缺陷 检测,缺陷放大(无评审),0,0,10,0%,10,6,4,6,4*1.5,X=1.5,25,0%,37,10,27,10,27*3,X=3,25,20 %,94,94,0,0,50 %,47,0,0,50 %,24,0,0,50 %,12,概要设计,详细设计,编码/单元测试,到集成,集成测试,确认测试,系统测试,潜伏的错误,缺陷放大（有评审）,0,0,10,70%,3,2,1,2,1*1.5,25,50%,15,5,10,5,10*3,25,60 %,24,24,0,0,50 %,12,0,0,50 %,6,0,0,50 %,3,概要设计,详细设计,编码/单元测试,到集成,集成测试,确认测试,系统测试,潜伏的错误,第五节 正式技术评审 正式评审的目标： 1.在软件的任何一种表示中发现功能、逻辑或实现的错误 2.证实经过评审的软件的确满足需求 3.保证软件的表示符合预定义的标准 4.得到一种一致的、具有连续性的方式开发的软件（风格、实现等方面） 5.使项目易于管理 FTR同时也是一个连续的培训过程，以会议形式进行，并有适当的计划、控制和参与，才能成功。 5.1 评审会议 评审会议的约束：人员35人之间；提前准备，每人占用不超过2小时；会议时间不超过2小时。 评审会议的组织 评审会议的结果 5.2 评审报告和记录保存 评审问题列表 评审总结报告 建立跟踪规程,5.3 评审的指导原则 评审原则的最小集合有十条： 评审产品，而不是评审生产者； 制定日程并遵守规程； 限制争论和辩驳； 对问题发表见解，但不要试图解决所有的问题； 做书面笔记； 限制参与人数并坚持事先做准备； 为每个可能要评审的工作产品建立一个检查表（checklist)； FTR分配资源和时间； 对所有评审者进行有意义的培训； 评审以前所做的评审。,第六节 正式评审实战 1.讲解“正规评审指南” 2.Checklist (检查表）编写指南 3. 讲解“正规评审”之后应该提交的成果 评审问题记录表 评审总结报告,第8节 ISO9000及CMM的介绍 8.1 ISO9000 ISO9000-3 标准的内容要点： 1。仅仅适用于依据合同的“定制开发” 2。对供需双方领导的责任作了明确的规定 3。从双方签约、设计、实现到维护整个软件生命周期的全部工序进行审查，并彻底文档化，作为质量保证体系实施的 “证据” 4。规定了双方签约、设计、实现到整个软件生命周期中应该实施的质量保证活动 5。规定了供应方应实施内部质量审核制度 6。规定了供应方对每个合同条目进行审查 7。对需求规格说明有详细的规定 8。开发计划管理 9。质量计划管理 10。设计和实现,11。测试和验证 12。验收 13。复制、交付和安装 14。维护（对维护活动的计划、规定和支持等） 15。配置管理（版本变更和升级） 16。文档控制（各种文档的建立、审批和发布等） 17。质量记录（包括质量记录确认、收集、索引、文件格式、存储和维护等） 18。测量 19。采购 20。培训 21。其他 11.2 一个具体的ISO9000的实例 11.3 CMM介绍,第二部分 软件配置管理 （Software Configuration Management) 第一节 SCM介绍 概念：软件配置管理是一组活动,是设计用来标识变更的工作产品、建立它们之间的关系、定义管理这些工作产品不同版本的机制、控制这些变更以及审计和报告所发生的变更。 人员：每一个涉及到软件工程过程的人员均在某种程度上和SCM相关联。一般情况下需要专门的SCM小组或专门的技术人员来管理和支持。 为什么重要：举例： 步骤：1）在开发过程中每个中间产品惟一的标识。 2）建立版本和变更控制机制。 3）为保证变更的质量，变更必须被审计。 4）对变更需进行统计、跟踪和实行报告制度。 产品：定义配置管理计划，其中涉及SCM的策略；当SCM启动之后，需产生软件变更请求单、报告单和变更单。,配置管理的作用：SCM是被应用于整个软件过程中的庇护性活动。因为变更是随时发生的，故SCM的作用表现在： 1）标识变更 2）控制变更 3）保证变更的实现 4）向相关的人员报告变更 CMM 对配置管理的定义： 区分软件维护和软件变更： 第二节 软件配置管理（SCM) 软件配置的内容：计算机程序，文档和数据。 变更源（四点）： 2.1 基线（baseline) 定义：已经经过正式评审和批准的某规约或产品（可能是中间产品 ），是后续开发的基础，并且只能在正式的变化控制流程下做修改。,项目数据库,基线： 系统规约 软件需求 设计规约 源代码 测试计划/规程/数据 工具等,SCI,SCI,SCI,SCI,软件工 程任务,修改,正式技 术评审,提取,SCM控制,认可,存储,作为基线的SCI和项目数据库,2.2 软件配置项,设计规约,数据库设计 体系结构设计 模块设计 接口设计,数据模型,构件N,接口描述 算法描述 PDL,源代码,测试规约,测试计划 测试规程 测试案例,软件配置项（SCI） 配置对象 配置对象间的关系：组合关系和相互关系 第三节 SCM过程 配置管理是软件质量管理的重要一环，主要职责是控制变更，但变更有很多控制环节，所以关于SCM过程的讨论会涉及到一系列复杂的问题： 开发机构或项目组如何管理配置项，使得变更高效可靠？ 如何在软件版本分布之前和之后控制变更？ 谁负责批准变更并给变更以优先级？ 采用什么机制去通知他人变更已经发生？ 从这些问题中我们可以得出SCM的五个任务的定义： 标识、版本控制、变更控制、配置审计和报告。 第四节 配置管理中的对象标识 基本对象 聚合对象,每个对象有一组惟一的标识它的特征：名字、对象的描述 名字（有一定的命名规则）：是无二意的地标识一个对象的一个字符串。 对象描述：是一个数据项列表，包括 1）该对象所表示的SCI类型 2）项目标识符 3）变更/版本信息 理解“对象的演化图” 第四节 版本控制 是将规程和工具相结合来管理在软件工程过程中所创建的配置对象的不同版本。通过“属性元组”等其他技术来控制完整版本中的“变体”。 第五节 变更控制 变更请求单、变更报告单、工程变更单（engineering change order ）或变更确认单 访问控制 同步控制,对象 1.0,对象 1.1,对象 1.2,对象 1.3,对象 1.4,对象 2.0,对象 2.1,对象 1.1.2,对象 1.1.1,来自用户（开发者）的变更请求,评估,生成评估报告,变更授权人决定,变更请求拒绝,通知用户和开发者,变更请求排入队列，ECO,指定人员修改,提取配置对象,进行修改,评审（审计）变更,提交修改的配置项,执行质量保证和测试活动,建立版本的适当标记,一般的变更控制过程,软件工 程师,配置对象 （修改后版本）,审计信息,提交,解锁,配置对象 （基线版本）,所有权信息,项目数据库,配置对象（基线版本）,提取,配置对象 （提出版本）,访问控制,加锁,访问和同步控制,第六节 配置审计 1）正式的技术评审 关注已经被修改的配置项的正确性，评估SCI，以确定它与其他SCI的一致性、遗漏及潜在的副作用。正式评审应该对针对于所有的变更。 2）软件配置审计 评估正式评审中没有考虑的那些特征，通过询问以回答下列问题： 工程变更单（ECO）中的相关内容已经完成了吗？ 是否已经进行了正式的技术评审了吗？ 变更过程中是否遵循了软件工程标准？ 在对SCI的修改的同时，是否有相关的详细comments? 在配置管理工具中是否标注了变更后的SCI状态？ 所有与该SCI相关的SCI相应的更新否？ 第七节