软件质量管理与测试3-SQA

软件质量管理与测试,软件质量管理与测试,软件质量保证,软件质量保证,概述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）简单而言就是管理软件的变化，应用于软件工程过程，通常由相应的工具、过程和方法学组成。在整个软件的开发活动中占有很重要的位置。软件配置管理的目的与益处有效的软件配置管理可以解决一些常见的问题；有效的软件配置管理可以节约用户资金；有效的软件配置管理可以提高软件开发管理的水平；有效的软件配置管理可以保护企业的知识财富。,软件配置管理-配置项,配置项定义软件配置控制配置项标识,软件配置管理-配置项的定义,所有在软件开发过程中产生的信息，总称为软件配置项，主要包括：计算机程序（源代码和可执行程序）计算机程序描述文档（对技术开发者和用户）数据（包含在程序内部或外部）,软件配置管理-配置项内容,软件配置管理-软件配置控制,配置控制是配置管理的核心工作。配置控制主要包括：存取控制：设定了软件开发人员对软件基准库的存取权限，保证软件开发过程及软件产品的安全性；版本控制：是配置管理的基本要求，使得组织在任何时刻都可以获得配置项的任何一个版本；变更控制：为软件产品变更提过了一个明确的流程，要求任何进行配置管理的软件产品变更都要经过相应的授权与批准才能实施；产品发布：保证了提交给客户的软件产品是完整的、正确的。,软件配置管理-配置项标识,软件配置项标识是管理配置的前提。标识包括文件名和版本。确定配置项：软件项目在开发过程中会产生成千上百个配置项，那么确定配置项是很重要的；明确配置项标识的要求：项目组人员按照标识规则对配置项进行标识，最后提交给配置管理员纳入配置库统一管理；配置项命名：(1)唯一性：在一个项目内不能出现重名，以避免混淆；(2)可追溯性：系统的要求，即名字应能体现相邻配置项之间的关系。,软件配置管理-基线,常用软件基线：,软件配置管理-基线属性与优点,基线是软件生存期各开发阶段末尾的特定点，也称里程碑。基线的属性：通过正式评审过程建立；存在于基线库，对基线的变更接受更高权限的控制；基线是进一步开发和修改的基准和出发点；进入基线前，不对变化进行管理；进入基线后，对变化进行有效管理；不会变化的内容不纳入基线，变化对其它无影响的也不纳入基线；基线具有名称、标识符、版本、日期等属性；交付给客户的基线成为一个Release，内部开发用的基线为一个Build。基线的优点重现性：当更新不稳定或不可信时，基线提供一种取消变更的方法；可追溯性：建立项目工件之间的前后继承关系；版本隔离：新项目与随后对原始项目所进的变更进行隔离。,软件配置管理-基线种类,功能基线(FunctionalBaseline)指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。指派基线(AllocatedBaseline)指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。产品基线(ProductionBaseline)指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。,软件配置管理-软件过程中的配置基线,软件配置管理-版本控制,版本的访问与同步控制版本分支和合并版本的历史记录,软件配置管理-版本的控制与同步控制,版本的访问控制工作区域中的源文件是从库中恢复得到的一个复制文件，它可以是可“写”的，也可以是可“读”的。一般有两种工作模式：一是在工作区域一旦有“读”请求，就做一次恢复操作，获得复制文件，当“读”操作结束，该复制文件被删除；二是仅当软件库中的内容发生更改时，才发生交互，而不是每次“读”操作都与软件库中的文件发生交互。版本的同步控制同步控制实际上是版本的检入检出控制：检入：将软件配置项从用户的工作环境存入到软件配置库的过程；检出：将软件配置项从软件配置库中取出的过程。,软件配置管理-访问和同步控制的流程图,软件配置管理-版本分支和合并,版本分支版本分支人工方法就是从主版本复制一份文件，做上标记；实行版本控制之后，版本的分支是一份复制文件，这时的复制过程和标记动作由版本系统自动完成。版本合并版本合并是通过对文件的比较来进行合并。有两种途径：一种是将版本A的内容附加到版本B中；另一种是合并A和B的内容，形成新的C；后一种途径更容易理解，也符合软件开发的思路。,软件配置管理-版本的历史记录,文件和目录的版本演化的历史可以形象的表示为图形化的版本树；版本树由版本依次连接形成，每个结点代表一个版本，根结点是初始版本，叶结点代表最新的版本；典型的软件系统包含多个文件和目录，每个文件和目录都有自己的版本树；版本的历史记录有助于对软件配置项进行审计，有助于追踪问题的来源；版本的历史记录应该包含版本号、修改时间、修改者、修改描述这些最基本的内容。,软件配置管理-版本树,最简单的版本树只有一个分支，就是版本树的枝干；复杂的版本树除了主干外，还可以包含很多的分支，分支可以进一步包含子分支。,软件配置管理-变更控制,变更类型变更请求管理变更管理的实施步骤,软件配置管理-变更机制,CCB：变更控制委员会ChangeControlBoard,软件配置管理-变更类型,功能变更功能变更是为了增加或者删除某些功能、或者为了完成某个功能的方法而需要的变更；这类变更必须经过某种正式的变更评价过程，以估计变更需要的成本和其对软件系统其他部分的影响。缺陷变更缺陷修补是为了修复漏洞需要进行的变更。在项目前期，它是必须进行的，通常不需要从管理角度对这类变更进行审查和批准。在项目后期，如果发现错误的阶段在造成错误的阶段的后面，则必须遵照标准的变更控制过程来进行。,软件配置管理-变更请求管理,变更请求通常分为两个大类：增强请求：增强请求指系统的新增特征或对系统“预定设计”行为的变更。缺陷：指存在于一个已交付产品中的异常现象或缺陷。变更请求管理过程：变更请求提交变更请求接收变更请求评估变更请求决策变更请求实现变更请求验证变更请求完成,软件配置管理-变更请求管理流程,软件配置管理-变更管理的实施步骤,变更请求提交缺陷和增强请求通常在请求起源和收集信息类型上不同。变更请求接收项目必须建立接收提交的变更请求并进行跟踪的机制。指定接收和处理变更请求的责任人，确认变更请求。变更请求评估大多数机构根据请求的类型是缺陷还是增强而使用不同的评估过程。变更请求决策决策阶段是当选择实现一个变更请求时所做出的决定，如推迟此次实施或者永远不进行实施等。缺陷和增强请求几乎总是以不同方式进行处理。,软件配置管理-变更管理的实施步骤,变更请求实现增强请求实现较之缺陷实现需要更多的设计工作，这是因为增强请求经常涉及新特性或新功能。另一方面，缺陷修复需要建立一个环境，在该环境中可以对缺陷进行重现并测试相应的解决方案。变更请求验证验证发生在最终测试及文档制作阶段。增强请求的测试通常涉及验证所做变更是否满足该增强请求的需要。缺陷测试则简单的验证开发人员的修复是否真正消除了该缺陷。变更请求完成完成是变更请求的最终阶段，这可能是完成了一项请求或者决定不实现某一请求。在完成阶段的主要步骤是由提交请求的原有请求者中止这一循环过程。,软件配置管理-软件配置管理系统,软件配置标准并发版本系统（CVS）IBM-Rational的ClearCase基于构件复用的配置管理系统JBCM,软件配置管理-系统功能,并行开发系统修订版管理版本控制产品发布管理建立管理过程控制变更请求管理代码共享,软件配置管理-软件配置标准,软件配置标准和指南,软件配置管理-并发版本系统（CVS）,CVS是并发版本系统（ConcurrentVersionsSystem）的意思，主流的开放源码，网络透明的版本控制系统。它的客户机/服务器存取方法使得开发者可以从任何因特网的接入点存取最新的代码。它的无限制的版本管理检出模式避免了通常因为排它检出模式而引起的人工冲突。它的客户端工具可以在绝大多数的平台上使用。,软件配置管理-CVS基本概念,CVS基本概念：仓库：它是CVS服务器的根目录，所有的工作都保存在这个仓库；模块：模块里面放的是一个项目的所有文件；导入：将本地软件项目导入到CVS仓库中；导出：将仓库中的一个模块中的东西导到本地工作目录下；提交修改：将本地修改的文件提交到CVS仓库；同步：从CVS下载修改过的文件来更新本地文件；文件版本：指的是单个文件版本；发行版本：整个产品的版本；标签：对一个文件或多个文件给的符号名。,软件配置管理-CVS简单命令集,CVS简单命令集：检出源文件提交命令删除增加文件提交源文件,软件配置管理-CVS文件状态,软件配置管理-使用CVS进行版本控制,检出小组成员从CVS服务器上检出各自负责的模块进行开发。结束后把文件提交到CVS服务器；提交新文件在项目中有新的文件加入，要提交到服务端；提交修改文件只有一个小组成员对文件进行修改的情况；两个或两个以上的小组成员对同一个文件的不同部分进行修改；两个或两个以上的小组成员对同一个文件的相同部分进行修改。标记分支管理,软件配置管理-IBM-Rational的ClearCase,RationalRose公司推出的软件配置管理工具ClearCase提供了比较全面的配置管理支持，包括：版本控制工作空间管理建立管理过程控制,软件配置管理-ClearCase版本控制,ClearCase的核心功能是版本控制支持广泛的文件类型在版本树中观察构件发展的过程对目录和子目录进行版本控制使用常见的检出/编辑/检入范例丰富的数据信息自动的比较和版本间的归并,软件配置管理-ClearCase工作空间管理,空间管理：即保证开发人员拥有自己独立的工作环境，拥有自己的私人存储区，同时可以访问成员间的共享信息。ClearCase给每一位开发者提供了一致、灵活的工作空间域。版本间的透明访问。开发人员不必进入ClearCase界面就可以直接完成相关操作。通过规则试图选择并显示版本从没有安装ClearCase的主机平台进行视图访问,软件配置管理-ClearCase过程控制,ClearCase为团队通信、质量保证、变更管理提供了非常有效的过程控制和策略控制机制：为对象分配属性超级链接历史记录定义事件触发机制访问控制查询功能,软件配置管理-基于构件复用的配置管理系统JBCM,青鸟软件配置管理系统（简称JBCM系统）是一套在软件开发中用于配置管理的系统，可用于管理软件开发过程中的各种产品，帮助管理软件开发中出现的各种变化和演变方向，跟踪软件开发的过程，保存软件开发过程中待开发软件系统的状态，供用户随时提取，简化开发过程的管理工作，有助于软件开发和维护工作的有序进行。,JBCM的软件开发模型项目/构件结构,在JBCM系统中，软件开发主要分为两个层次：项目和构件。项目指的是一个可以独立开发的软件系统。构件是JBCM系统进行版本管理的基本单位。一个项目可以含有一个或多个构件。创建项目和构件文件的版本结构，它以版本树的结构跟踪记录文件的变化。构件的版本结构，也是以版本树来表示。但是它引入了分支的概念，每个分支有自己的版本变化树，反映构件的一个变化方向。文件版本和构件版本之间的关系,JBCM的软件开发模型构件划分方法,JBCM的软件开发模型JBCM中构件的版本树,JBCM的软件开发模型主要功能,用户管理用户管理是JBCM的重要部分，分为：系统级、项目级、构件级。版本管理版本管理是配置管理的核心。在JBCM系统中，文件的版本管理隐藏在构件版本管理之下。构件管理配置管理是构件版本管理基础上的高层应用功能。团队管理JBCM系统的控制，可以明确的检出各用户的工作状态与工作资源。,JBCM的软件开发模型用户权限,JBCM的软件开发模型文件的操作权限,软件配置管理-实施流程,软件配置管理-实施流程,软件配置管理-实施流程,配置管理计划1、软件开发者在制定开发计划的同时制定，包括：项目的内容，基线定义及管理要素，组织结构，配置标识、控制、状态记录、核查及认证。2、成立配置控制小组。做（同变更控制）检查1、保持纳入基线的软件状态并使其可见。2、验证配置过程是否按计划执行。3、验证变更请求文档是否包含要求的信息，是否已按要求更新。实施形成报告，分析问题，持续改进。,软件评审,为什么需要评审软件评审的角色和职能评审的内容评审的方法和技术准备评审会议召开评审会议跟踪和分析评审结果如何实施成功的评审,软件评审-为什么需要评审,从成本上来衡量缺陷发现得越晚纠正费用越高，而软件评审的重要目的就是通过软件评审尽早的发现产品中的缺陷，减少大量的后期返工。,软件评审-为什么需要评审,从技术上来衡量前一阶段的错误自然会导致后一阶段的工作结果中有相应的错误，而且错误会逐渐累积，越来越多。,软件评审-软件评审的角色和职能,协调人（负责人）作者评审员专家用户代表质量保证代表记录员其它相关方,软件评审-评审的内容,管理评审技术评审文档评审过程评审,软件评审-管理评审,由最高管理者就质量方针和目标对质量体系的现状和适应性进行正式评价。,软件评审-管理评审,质量管理体系运行状况内、外部审核结果改进、预防和纠正措施的状况上次管理评审提出的改进措施实施情况及验证信息,管理评审,质量体系的总体评价质量管理体系及其过程的改进产品是否符合要求的评价，有关产品的改进新资源的需求的决定和措施,输入,输出,对质量体系进行回顾和总结并确保其适宜性、有效性和充分性,软件评审-技术评审,评审的目的评审的内容评审检查单其他必需文档,技术评审,技术评审报告会议的基本信息存在的问题和建议措施评审结论和意见问题跟踪表技术评审问答记录,输入,输出,软件评审-文档评审,正确性完整性一致性有效性易测性模块化-系统和文档描述必须深入到模块。模块化即模块的独立性清晰性可行性可靠性可追溯性,软件评审-过程评审,过程评审的目的：评估主要的质量保证流程考虑如何处理/解决评审过程中发现的不符合问题总结和共享好的经验指出需要进一步完善和改进的地方评审结束后，评审小组需要提交一份评审报告，其中包括：评审记录评审后，对现有流程的说明和注释评审小组的建议,软件评审,过程评审流程,软件评审-评审的方法和技术,评审的方法评审的技术,软件评审-评审的方法,临时评审（Adhocreview）轮查（Pass-round）走查（Walkthrough）小组评审（GroupReview）审查（Inspection）,软件评审-评审的方法,审查、小组评审和走查异同点比较表,软件评审-评审的方法,如何选择正确的评审方法？选择评审方法最有效的标准是：“对于最可能产生风险的工作成果，要采用最正式的评审方法。”例如：核心代码的失效也会带来很严重的后果，所以也应该采用审查或小组评审的方法进行评审，而一般的代码则可以采用临时评审、同桌评审等比较随意的评审方法。,软件评审-评审的技术,缺陷检查表它列出了容易出现的典型错误，是评审的一个重要组成部分。规则集类似于缺陷检查表，通常是业界通用的规范或者企业自定义的各种规则的集合。评审工具的使用合理的利用工具，如NASA开发的ARM（自动需求度量）从不同角色理解不同的角色对产品/文档的理解是不一样的。场景按照用户使用场景对产品/文档进行评审。,软件评审-准备评审会议,评审计划各阶段评审计划的内容包括：各个阶段的评审时间、评审方式、评审组成员等。SQA在其提交的质量保证计划中，应根据各个阶段的评审计划，制定相应的评审检查点。,软件评审-准备评审会议,组建评审组项目组提出评审组长和评审组成员名单建议，质量组根据项目组的建议，与相关部门或人员（如外协单位负责人）进行协商确定。选定评审组长对评审来说是非常重要的，评审组长需要