软件质量管理与测试软件质量管理与测试软件质量保证软件质量保证概述SQA人员素质基本目标工作内容工作方法软件配置管理评审及检查软件质量保证-概述软件质量保证(SoftwareQualityAssur-ance,SQA)是建立一套有计划,系统的方法,来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。软件质量保证-概述QA的由来:我们知道,国外很多的大公司,QA的职责就是测试(主要是系统测试),比如IBM、CA、PeopleSoft等。其实在最初,几乎所有的公司都是这样的。后来,由于缺乏有效的项目计划和项目管理,留给系统测试的时间很少;并且需求变化太快,没有完整的需求文档,测试人员就只能根据自己的想象来测试。这样一来,测试就很难保障产品的质量,事先预防的QA职能就应运而生。事先预防其实是借鉴了全面质量管理(TotalQualityManagement,TQM)的思想,而且也符合软件工程“缺陷越早发现越早修改越经济”的原则。软件质量保证-概述QA的现在目前,实施能力成熟度模型(CapabilityMaturityModel,CMM)的企业越来越多。CMM模型就要求建立QA角色。这里的QA类似于过程警察,主要职责是检查开发和管理活动是否与已定的过程策略、标准和流程一致,检查工作产品是否遵循模板规定的内容和格式。在这些企业中,一般还要求QA独立于项目组,以保障评价的客观性。从国内来看,多数的QA没有技术背景,检查出的偏差多为鸡毛蒜皮,再加上自己没有令人信服的背景,领导也不支持,当然做起来就很困难了。因此,QA工作本身要求QA人员具有软件工程的知识、软件开发的知识、行业背景的知识、数理统计的知识、项目管理的知识、质量管理的知识等等。软件质量保证-概述QA的未来:从某种程度上说,独立的QA审查机制是瀑布模型的产物。随着现代软件开发技术的演变,螺旋模型和迭代模型的兴起,QA机制正在悄然发生变化。这种变化就是从独立专职的QA向贯穿过程的兼职QA演变。为什么会发生这种改变呢?无论是何种先进的方法论都是先产生架构,然后再增量开发,直到完成。这种模式中,需求和设计缺陷在各个迭代周期被尽早发现和修复,质量也内建于架构和过程中,项目的成本和进度也得到保障。到那时,是不是独立的QA就不复存在了呢?有些成熟度较低的企业还是需要的,主要是保证过程执行的有效性和评价的客观性。软件质量保证-概述QA和QC:QC:检验产品的质量,保证产品符合客户的需求,是产品质量检查者。QA:审计过程的质量,保证过程被正确执行,是过程质量审计者。检查:就是我们常说的找茬,是挑毛病的;审计:确认项目按照要求进行的证据;QC进行质量控制,向管理层反馈质量信息;QA则确保QC按照过程进行质量控制活动,按照过程将检查结果向管理层汇报。QA检查项目按照过程进行了某项活动没有,产出了某个产品没有;而QC来检查产品是否符合质量要求。软件质量保证-SQA人员素质1.SQA人员(简称SQA)要有很强的沟通能力。SQA不在项目中,是独立于软件项目的第三方,但要了解项目的开发过程和进度,捕捉项目中不符合要求的问题,这就要求SQA能够深入项目,和软件开发经理以及项目组开发人员保持很好的沟通,这样才能及时获得真实的项目情况。2.SQA要熟悉软件开发过程。作为SQA,既然要确保项目组制定的计划、标准和规程要符合项目组要求,那么,SQA自己就要了解软件项目开发过程以及企业内部已有的开发过程规范。3.SQA本身要有很强的计划性。SQA一方面要监督软件项目组编写计划,另一方面SQA自身工作也要有计划。软件质量保证-SQA人员素质4.SQA要能应对繁杂的工作。作为SQA,在跟踪项目进行过程的时候要对项目组的很多工作产品进行审计,而且会参与项目组中的多种活动。同时一个SQA还有可能会面对多个项目组,所以任务相对繁杂细碎,这就要求SQA在处理这些事物的时候要耐心细致。5.SQA要客观,有责任心。作为第三方对项目过程进行监督,SQA要能保持自己的客观性,不能一味讨好项目经理,也不能成为项目组中的宪兵,否则会影响工作的开展。对于项目组中多次协调解决不了的问题,能够向项目的高层经理进言,完成SQA的使命。软件质量保证-主要目标1、通过监控开发过程保证产品质量。2、确保产品及开发过程不符合问题得到处理,必要时将问题反映给高级管理者。3、确保产品及开发过程符合相关标准与规程。4、确保项目组制定的计划、标准、规程适合项目组要求,同时满足评审及审计需要。5、收集好的实施方法、发现实施不利的原因,以便持续改进。软件质量保证-工作内容1、为项目准备SQA计划。该计划在制定项目计划时确定,由所有感兴趣的相关部门评审。包括:需要进行的审计和评审、项目可采用的标准、错误报告和跟踪的规程、由SQA小组产生的文档、向软件项目组提供的反馈数量。2、参与开发项目的软件过程描述。评审过程描述以保证该过程与组织政策、内部软件标准、外界标准以及项目计划的其他部分相符。3、评审各项软件工程活动,对其是否符合定义好的软件过程进行核实。记录、跟踪与过程的偏差。软件质量保证-工作内容4、审计指定的软件工作产品,对其是否符合事先定义好的需求进行核实。对产品进行评审,识别、记录和跟踪出现的偏差;对是否已经改正进行核实;定期将工作结果向项目管理者报告。5、确保软件工作及产品中的偏差已记录在案,并根据预定的规程进行处理。6、记录所有不符合的部分并报告给高级领导者。7、收集新方法,提供持续改进的依据。软件质量保证-工作方法软件质量保证-工作方法1、计划针对具体项目制定SQA计划,确保项目组正确执行过程。制定SQA计划应当注意如下几点:有重点:依据企业目标及项目情况确定审计重点明确审计内容:明确审计哪些活动,那些产品明确审计方式:确定怎样进行审计明确审计结果报告的规则:审计的结果报告给谁2、做执行计划软件质量保证-工作方法3、检查(审计/证实)依据SQA计划进行SQA审计工作,按照规则发布审计结果报告。注意审计一定要有项目组人员陪同,不能搞突然袭击。双方要开诚布公,坦诚相对。审计的内容:是否按照过程要求执行了相应活动,是否按照过程要求产生了相应产品。4、实施(问题跟踪)对审计中发现的问题,要求项目组改进,并跟进直到解决。软件质量保证-软件配置管理概述配置项基线版本控制变更控制软件配置管理系统实施流程软件配置管理-概述软件配置管理的概念SCM(SoftwareConfigurationManagement)简单而言就是管理软件的变化,应用于软件工程过程,通常由相应的工具、过程和方法学组成。在整个软件的开发活动中占有很重要的位置。软件配置管理的目的与益处有效的软件配置管理可以解决一些常见的问题;有效的软件配置管理可以节约用户资金;有效的软件配置管理可以提高软件开发管理的水平;有效的软件配置管理可以保护企业的知识财富。软件配置管理-配置项配置项定义软件配置控制配置项标识软件配置管理-配置项的定义所有在软件开发过程中产生的信息,总称为软件配置项,主要包括:①计算机程序(源代码和可执行程序)②计算机程序描述文档(对技术开发者和用户)③数据(包含在程序内部或外部)软件配置管理-配置项内容配置项包含内容项目管理过程文档项目任务书;项目计划;项目周报;个人日报和周报;项目会议纪要;培训记录和培训文档;QA过程文档QA不符合报告;QA周报;评审记录;工作产品需求文档;设计文档;代码;测试文档;软件说明书和手册;项目中使用的第三方产品例如:Oracle,Java等软件配置管理-软件配置控制配置控制是配置管理的核心工作。配置控制主要包括:①存取控制:设定了软件开发人员对软件基准库的存取权限,保证软件开发过程及软件产品的安全性;②版本控制:是配置管理的基本要求,使得组织在任何时刻都可以获得配置项的任何一个版本;③变更控制:为软件产品变更提过了一个明确的流程,要求任何进行配置管理的软件产品变更都要经过相应的授权与批准才能实施;④产品发布:保证了提交给客户的软件产品是完整的、正确的。软件配置管理-配置项标识软件配置项标识是管理配置的前提。标识包括文件名和版本。确定配置项:软件项目在开发过程中会产生成千上百个配置项,那么确定配置项是很重要的;明确配置项标识的要求:项目组人员按照标识规则对配置项进行标识,最后提交给配置管理员纳入配置库统一管理;配置项命名:(1)唯一性:在一个项目内不能出现重名,以避免混淆;(2)可追溯性:系统的要求,即名字应能体现相邻配置项之间的关系。软件配置管理-基线常用软件基线:系统工程需求分析软件设计代码测试系统规格说明书软件需求规格说明书设计规格说明书源代码测试计划过程/数据可操作的系统软件配置管理-基线属性与优点基线是软件生存期各开发阶段末尾的特定点,也称里程碑。基线的属性:通过正式评审过程建立;存在于基线库,对基线的变更接受更高权限的控制;基线是进一步开发和修改的基准和出发点;进入基线前,不对变化进行管理;进入基线后,对变化进行有效管理;不会变化的内容不纳入基线,变化对其它无影响的也不纳入基线;基线具有名称、标识符、版本、日期等属性;交付给客户的基线成为一个Release,内部开发用的基线为一个Build。基线的优点重现性:当更新不稳定或不可信时,基线提供一种取消变更的方法;可追溯性:建立项目工件之间的前后继承关系;版本隔离:新项目与随后对原始项目所进的变更进行隔离。软件配置管理-基线种类功能基线(FunctionalBaseline)指在系统分析与软件定义阶段结束时,经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明;或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明;或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。指派基线(AllocatedBaseline)指在软件需求分析阶段结束时,经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。产品基线(ProductionBaseline)指在软件组装与系统测试阶段结束时,经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。软件配置管理-软件过程中的配置基线需求分析设计编码测试计划基线需求基线设计基线编码基线测试基线计划项目开发计划用户手册需求规格分析详细设计说明书概要设计说明书源代码测试报告软件配置管理-版本控制版本的访问与同步控制版本分支和合并版本的历史记录软件配置管理-版本的控制与同步控制版本的访问控制工作区域中的源文件是从库中恢复得到的一个复制文件,它可以是可“写”的,也可以是可“读”的。一般有两种工作模式:一是在工作区域一旦有“读”请求,就做一次恢复操作,获得复制文件,当“读”操作结束,该复制文件被删除;二是仅当软件库中的内容发生更改时,才发生交互,而不是每次“读”操作都与软件库中的文件发生交互。版本的同步控制同步控制实际上是版本的检入检出控制:检入:将软件配置项从用户的工作环境存入到软件配置库的过程;检出:将软件配置项从软件配置库中取出的过程。软件配置管理-访问和同步控制的流程图软件工程师软件配置库检入检出访问控制配置对象(修改版本)配置对象(基线版本)审计信息解锁拥有者信息加锁配置对象(基线版本)配置对象(提取版本)软件配置管理-版本分支和合并版本分支版本分支人工方法就是从主版本复制一份文件,做上标记;实行版本控制之后,版本的分支是一份复制文件,这时的复制过程和标记动作由版本系统自动完成。版本合并版本合并是通过对文件的比较来进行合并。有两种途径:一种是将版本A的内容附加到版本B中;另一种是合并A和B的内容