软件质量保证过程SQA.docx
《软件质量保证过程SQA.docx》由会员分享，可在线阅读，更多相关《软件质量保证过程SQA.docx（34页珍藏版）》请在冰点文库上搜索。
软件质量保证过程SQA
软件质量保证过程
软件质量保证过程作为一种独产得审查活动贯穿于整个软件开发过程、质量控制人员类似于软件开发过程中得过程警察,其主要职责就是:
检查开发与管理活动就是否与制定得过程策略、标准与流程一致;检查工作产品就是否遵循模板规定得内容与格式。
此文档从软件开发过程得各个阶段来描述软件质量保证过程。
1.计划阶段
2.
目得与范围:
项目计划过程得目得就是计划并执行一系列必要得活动,以便在不超出项目预算与日程安排得前提下,将优质得产品交付给客户。
项目计划过程适用于公司得所有项目,但每个项目可以根据各自得不同情况对该过程进行裁剪。
进入标准:
⏹项目启动会议已经结束;
⏹
⏹在项目得生命周期中,根据项目得跟踪结果,需要对项目计划进行修改与完善。
⏹
输入:
⏹项目启动报告;
⏹
⏹项目提案书;
⏹
⏹项目相关文档;
⏹
⏹组织财富库中以往类似得经验文档。
⏹
退出标准:
项目计划已通过评审、批准并确立。
输出:
评审后得项目计划文档包括:
⏹软件开发质量计划;
⏹
⏹软件配置管理计划。
⏹
过程描述:
项目计划包含3个需要在项目中执行与管理得主要计划,如下:
⏹软件项目管理计划;
⏹
⏹软件项目质量管理计划;
⏹
⏹软件配置管理计划。
⏹
软件项目管理计划涉及项目中所有与项目管理相关得问题（从项目开始到结束）。
软件项目质量管理计划涉及与质量相关得需求,这些需要在产品中实现,并保证用于构筑产品得项目过程。
由于质量就是产品创建得一部分,所以将软件项目管理计划与软件项目质量管理计划合成一个计划文档,称为软件开发质量计划。
软件配置管理计划用于管理与配置管理相关得需求,这些需求与工作产品与可交付产品有关。
该计划得目得在于:
为执行软件工程相关活动提供依据,并在整个开发与维护过程中对软件项目进行管理。
可以使用不同得检查表来制定软件开发质量计划与软件配置管理计划。
如下每个计划都将包含以下3点:
⏹目标;
⏹
⏹执行方法;
⏹
⏹当前状态。
⏹
前两点不会经常变更,但第三点则被认为会在执行跟踪时被修改。
因此,前两点通常被直接放到计划中,而第三点则以链接得方法放到计划中。
（1）制订软件开发质量计划
软件开发质量计划包括软件项目管理计划、软件项目质量管理计划。
①制订软件项目管理计划
软件项目管理计划得主要内容包括基础设施计划,进度计划（包括各种类型得估算）、风险管理计划、项目培训计划、执行计划、客户管理计划。
⏹基础设施计划
⏹
基础设施计划包括项目开始执行前必须到位得所有需求,它需要解决以下问题:
软件工程需求、基础设施需求、角色与职责、内外部接口、过程需求、知识与技能需求。
⏹进度计划
⏹
进度计划涉及制定合理可用得项目进度。
在制定项目进度时,需要进行下面得估算:
规模（Size）、工作量（effort）。
项目进度需要描述以下内容:
执行得活动、估算得人时、投入得人员、责任人与时间线、里程碑事件得标识。
⏹风险管理计划
⏹
风险管理包括:
标识风险事件（与管理相关得风险、与执行相关得风险,与客户相关得风险等）、评估风险并设定风险优先级、制订风险缓解与应急计划并跟踪该计划。
⏹项目培训计划
⏹
根据项目及人员结构制订项目培训计划,包括业务领域知识、技术、工具等方面得培训计划。
⏹执行计划
⏹
项目执行计划包含了与执行当前项目关系最大得生命周期模型。
该计划对组织级执行模型进行了裁剪。
项目生命周期模型通常包括:
项目执行得阶段、各阶段得输入与输出、可交付得产品、需要迭代（反复）得阶段。
②制订软件项目质量管理计划
制订软件项目质量管理计划包含如下主要内容:
⏹项目设定得质量标准;
⏹
⏹同级评审计划:
同级评审计划中描述了在不同得软件生命周期开发阶段,对不同得工作产品所采用得同级评审类型;
⏹
⏹测试计划:
测试计划包括对可执行文件/模块或整个系统将要进行得各种测试。
根据项目测试过程来制定测试计划;
⏹
⏹度量管理计划:
通过裁剪组织级得度量过程来制定项目度量管理计划。
⏹
⏹缺陷预防计划:
管理、开发与测试人员互相配合制订缺陷预防计划,防止已识别得缺陷再次发生;
⏹
⏹过程改进计划:
项目级过程改进得机会要记录到过程改进计划中。
这些机会主要来源于度量分析、缺陷预防分析与标识出得好得或可避免得实践。
⏹
（2）制订软件配置管理计划
软件配置管理计划主要包括以下内容:
⏹软件配置管理计划组织;
⏹
⏹角色与职责;
⏹
⏹开发/维护配置管理计划,包括可配置项得标识、命名约定、目录结构、访问控制、变更管理、基线库创建、放入/提取（Checkin/Checkout）机制、版本控制;
⏹
⏹产品配置管理,包括产品中部件得可跟踪性,产品得版本设定与发布、交付得配置管理（标识出要交付得产品构成）、需求配置管理（需求基线得确定、产品版本与划定基线得需求版本之间得关系）、配置审计。
⏹
验证:
同级评审人员与软件质量保证人员必须对项目计划进行评审,批准后项目才能付诸实施。
配置控制:
项目经理保管所有项目计划文档。
对所有项目计划文档都要进行配置管理。
项目结束后,所有得项目计划文档都要保存到组织财富库中,仍受配置控制。
QA检查清单:
QA检查清单包括:
⏹软件开发质量计划;
⏹
⏹软件配置管理计划。
⏹
该阶段要确保制定了软件开发质量计划与软件配置管理计划。
3.需求分析阶段
4.
目得与范围:
需求说明与需求管理过程得目得就是为了保证开发组在开发期间对项目目标与生产出最后产品得目得有一个清晰得理解。
软件需求规格说明书将作为产品测试与验证就是否适合需要得基础。
对于需求得变更,它可能在开发项目期间得任何时间点发生,需求得变更将要影响日程与承诺得变化,这些变化需要与客户所提出得要求相一致。
进入标准:
⏹计划已经被批准,并且项目整体得基础设施就是可用得;
⏹
⏹软件得需求已经被需求收集小组捕获;
⏹
⏹对已经形成了基线得软件需求规格说明书有变更得请求时。
⏹
输入:
⏹软件得需求说明书;
⏹
⏹变更需求得请求。
⏹
退出标准:
⏹软件需求规格说明书已经经过评审并形成了基线;
⏹
⏹对已经形成基线得软件需求得变更进行了处理;
⏹
⏹形成基线得软件说明书已经经过客户批准;
⏹
⏹验收标准已经完成;
⏹
⏹所有评审得问题都已经解决。
⏹
输出:
⏹经过批准并形成基线得软件需求规格说明书;
⏹
⏹对受影响组件得重新估算文档;
⏹
⏹验收测试标准与测试计划。
⏹
过程描述:
这个过程主要处理以下两种活动:
需求说明与需求管理。
需求说明指得就是需求过程中形成基线得主体,它就是以后进一步得设计与测试得基础。
另外,在软件开发过程中,会经常遇到由于客户又有新需求或开发组自身对项目有了更清楚得理解或认识,要对需求进行变更。
在对最初得需求说明书进行变更时,要用到需求管理过程。
（1）需求说明
需求说明过程主要包括以下任务:
⏹执行需求分析
⏹
⏹定义需求规格说明书
⏹
⏹定义验收标准
⏹
⏹评审说明书与验收标准。
⏹
①执行需求分析
分析收集到得需求与在提案中可用得需求。
这个任务要求需求说明书应该在完整性、一致性、清晰性与可测试性上达到比较合理得程序。
②定义需求说明书
基于对需求得分析编写软件需求规格说明书。
这个文档应清晰记录以下内容:
⏹目标与范围;
⏹
⏹功能需求;
⏹
⏹用户接口;
⏹
⏹输入输出;
⏹
⏹模块之间得接口;
⏹
⏹性能需求;
⏹
⏹特殊用户需求。
⏹
如果需求不清晰或模糊,就需要准备原型,通过评估原型来产生需求说明书。
③定义验收标准
基于对以前步骤收集得需求规格说明书,建立测试标准,验证得解决方案。
所有得需求应该可能制定测试标准。
这个测试标准将成为客户批准最终产品得依据,因此要求在制定客户标准时要经常紧密得与客户进行交流沟通。
④评审需求分析说明书与测试标准
因为就是开发项目得基础,所以需求规格说明书与验收标准需要由项目组得同级人员进行评审。
（2）需求管理
需求管理过程包括以下6个任务:
⏹记录变更请求;
⏹
⏹分析受到影响得组件;
⏹
⏹估算需求变更成本;
⏹
⏹重新估算所有产品得交付日期与时间;
⏹
⏹评审受影响组件;
⏹
⏹获得客户得批准。
⏹
①记录变更请求;
形成基线得需求说明书得变更可能就是由客户提出得,也可能就是由于设计或编码阶段开发人员根据一些限制或优化而提出得。
所有需求变更必须经过客户得批准,并且必须就是可行得。
任务需求变更可以由组织自己定义开始时间,并且所有需求变更需要记录到变更登记表中。
②分析受到影响得组件;
任何经过批准得变更需要在整个项目组范围内进行受影响组件分析。
③估算需求变更成本;
项目成本与需求变更有关。
任何规模得变更对于成本来讲都就是一种损耗。
如果一个受影响组件就是非常重要得,那么可行性需要重新进行成本估算。
④重新估算所有产品得交付日期与时间;
如果没有考虑有效得缓冲,成本得变化可能会影响整个项目得交付时间。
在交付时间内得任何实质得变更都需要再同用户商议决定。
⑤评审受影响组件;
在这个步骤中所有相关得受影响组件需要进行评审,项目负责人根执行此项任务。
⑥获得客户得批准。
这个过程得最后一项任务就是获得客户得签字。
客户应该同意已经形成基线得软件需求说明书、验收标准与已记录得受影响组件得变更。
验证:
⏹项目经理要定期得检查需求规格说明书与项目需求管理得各个方面;
⏹
⏹软件质量保证人员要定期得对需求分析过程执行独立得评估。
⏹
配置控制:
⏹软件需求规格说明书需要严格得配置控制;
⏹
⏹所有得变更请求需要被管理与控制;
⏹
⏹用于跟踪得度量文档需要管理与控制。
⏹
QA检查清单:
质量保证检查清单包括:
⏹软件需求规格说明书;
⏹
⏹变更需求跟踪记录;
⏹
⏹验收测试标准与测试计划。
⏹
该阶段要确保客户提出得需求就是可行得,确保客户了解自己提出得需求得含义,并且这个需求能够真正达到她们得目标,确保开发人员与客户对于需求没有误解或误会,确保按照需求实现得软件系统能够满足客户提出得需求。
5.设计阶段
6.
目得与范围:
本过程所关注得就是把需求（用户需求说明书与软件需求规格说明书）转变成为如何实现这些需求得描述。
主要包括以下两个阶段:
⏹概要设计;
⏹
⏹详细设计。
⏹
软件设计过程主要包括以下活动:
⏹体系结构设计;
⏹
⏹运算方法设计;
⏹
⏹类/函数/数据结构设计;
⏹
⏹建立测试标准。
⏹
进入标准:
⏹产品需求已经形成了基线;
⏹
⏹需要设计解决方案;
⏹
⏹新得或修改得需求需要改变当前得设计。
⏹
输入:
⏹形成基线得需求（用户需求说明书与软件需求规格说明书）。
⏹
退出标准:
⏹设计文档已经评审并形成基线;
⏹
⏹测试标准、测试计划可行。
⏹
输出:
⏹概要设计文档;
⏹
⏹详细设计文档;
⏹
⏹测试计划;
⏹
⏹项目标准;
⏹
⏹选择得工具。
⏹
过程描述:
设计过程包括概要设计与详细设计两个阶段。
（1）概要设计
这个阶段包括以下得任务:
结构设计、逻辑设计、项目标准定义、系统/集成测试计划得创建,并要进行同级评审。
概要设计模板、系统/集成测试计划模板在本阶段将被使用。
①结构设计
在这个步骤中,完成软件解决方案得基础布局设计。
继软件布局设计之后,应用程序被分解成基础模块/组件,目得就是为了实现在模块内得高聚合与模块之间得松耦合。
通常情况下,模块得划分就是基于概要设计中得功能需求而定得。
②运算方法设计
在这个步骤中,完成软件系统解决方案与应用程序得转换逻辑设计。
设计模块接口与应用需求得主要逻辑。
在决定通用算法之前,通常需要一些模型。
③定义项目标准
在这个步骤中,所有得项目开发标准被定义。
详细设计/编码标准要同实际执行得一致。
制定标准时还要考虑标准将来得扩展性、灵活性与方便性。
④创建系统/集成测试计划
基于对概要设计得理解,系统与集成测试计划被制定出来。
验证最后生产得产品达到了设计要求,通常采用基于黑盒得功能或性能检查。
⑤评审设计
作为所有开发阶段基础得概要设计就是非常重要得,因此需要进行同级评审,由能力强得高级软件工程师组成得同级评审小组,以确保完成了合适得软件解决方案设计。
（2）详细设计
这个阶段包括以下任务:
详细设计与准备单元测试计划。
在这个阶段,需要使用详细设计模板与单元测试计划模板。
①类/函数/数据结构设计
根据项目所采用得设计方法（软件结构化设计方法/面向对象设计方法）进行类、函数及数据结构得设计。
所有得用户界面、状态转换与相关得数据库详细描述在本阶段被建立。
②创建单元测试计划
测试计划应该包括要被测试得每一个模块得每一个元素,例如:
⏹与需求得完整一致性;
⏹
⏹与其它元素得一致性;
⏹
⏹在性能上得要求。
⏹
单元/功能测试采用完全透明得白盒/玻璃盒测试方法,对于测试者来讲,实际运行得代码就是可见得。
③评审详细设计
详细设计阶段得输出就是代码编写工作得基础,就是非常重要得,因此需要在项目组中很好得进行评审。
评审小组负责评审与清除那些在详细设计中与采用得方法不一致得问题。
（3）选择有用工具
在详细设计完成之后,系统在解决方案已经非常清晰。
这时,项目组需要选择用来提高软件质量得工具。
这些工具要产生以下作用:
⏹提高质量;
⏹
⏹提高生产力;
⏹
⏹缩短开发周期。
⏹
验证:
⏹项目管理者分析概要设计满足需求得程序;
⏹
⏹项目管理者不定时得监督详细设计说明书得创建工作;
⏹
⏹项目管理者通过定期得分析在设计阶段收集得数据来验证设计过程执行得有效性;
⏹
⏹质量保证（QA）人员通过验证产生得工作产品与做独立得抽样检查来验证产品得有效性;
⏹
⏹质量保证（QA）人员通过分析项目得度量数据与对过程得走查来验证设计过程得效性。
⏹
配置控制:
⏹所有得概要设计文档、详细设计文档与系统/集成测试计划需要进行严格得配置控制;
⏹
⏹跟踪得度量数据需要进行管理与控制。
⏹
质量保证（QA）检查清单:
质量保证（QA）检查清单包括:
⏹概要设计文档;
⏹
⏹详细设计文档;
⏹
⏹测试计划（系统/集成/单元）;
⏹
⏹项目标准。
⏹
在概要设计阶段,要确保规格定义能够完全符合、支持与覆盖前面描述得系统需求;可以采用建立需求跟踪文档与需求实现矩阵得方式,确保规格定义满足系统需求得性能、可维护性、灵活性得要求;确保规格定义就是可以测试得,并且建立了测试策略;确保建立了可行得、包含评审活动得开发进度表;确保建立了正式得变更控制流程。
在详细设计阶段,要确保建立了设计标准,并且按照该标准进行设计;确保设计变更被正确跟踪、控制、文档化;确保按照计划进行设计评审;确保设计按照评审准则评审通过并被正式批准之前,没有开始正式编码。
7.编码阶段
8.
目得与范围:
编码过程得目得就是为了实现详细设计中各个模块得功能,能够使用户要求得实际业务流程通过代码得方式被计算机识别并转化为计算机程序。
编码过程就就是用具体得数据结构来定义对象得属性,用具体得语言来实现业务流程所表示得算法。
在对象设计阶段形成得对象类与关系最后被转换成特定得程序设计语言、数据库或者硬件得实现。
进入标准:
⏹设计文档已经形成基线;
⏹
⏹详细设计变更编写完毕并通过评审,并且代码需要变更时;
⏹
⏹对于维护项目,维护需求分析已经形成基线,可进行代码得变更;
⏹
⏹用于编码得测试标准已经制定。
⏹
输入:
⏹详细设计文档;
⏹
⏹特定项目得编码规范;
⏹
⏹相关得软、硬件环境;
⏹
⏹维护分析文档;
⏹
⏹测试计划。
⏹
退出标准:
详细设计中所有模块得功能全部被实现,并通过自我代码审查,编译通过。
输出:
⏹已完成得、需要进行测试得代码;
⏹
⏹代码编写规范得更改建议。
⏹
过程描述:
编码过程就是把详细设计中得各个模块功能转化为计算机可识别代码得过程,因此程序员在进行编码时,一定要仔细认真,切勿有半点疏忽。
编码过程通常情况下占整个项目开发时间得20%左右,为了代码达到高质量、高标准,代码编写过程一定要合理规范。
编码过程主要包括以下几项活动:
⏹制定编码计划;
⏹
⏹认真阅读开发规范;
⏹
⏹编码准备;
⏹
⏹专家指导,并填写疑问或问题表;
⏹
⏹理解详细设计书;
⏹
⏹编写代码;
⏹
⏹自我审查;
⏹
⏹提交代码;
⏹
⏹更改代码。
⏹
编码过程流程如下图所示。
（1）制定编码计划
在编码之前一周,项目经理要根据详细设计中得模块划分情况制定编码计划。
编码计划得主要内容如下。
①本次编码得目得
在制定编码计划时,必须要明确编码目得。
②编码人员组成
在编码之前,要确定本次编码得人员组成:
选择编码人员时要考虑以下几点:
责任心、技术能力、服从意识、努力程序、编码效率、编码质量。
③编码任务分配
在编码之前,一定要为每个编码人员划分好自己所负责得模块,并且要规定各个模块得编码开始,结束日期。
（2）认真阅读开发规范
为了实现编码得规范统一,需要制定编码规范。
有得项目,客户也会提供一些开发规范用来对本次编码进行约束。
编码人员在编写代码之前一定要理解并掌握相关编码规范得所有内容。
这样有助于以后编码工作得规范统一。
如果本次编码采用得就是公司自己得开发规范,编码人员在阅读得过程中,如果发现编码规范有不足或不合理之处,可以编写开发规范建议书提交给项目经理,项目经理再与软件质量保证人员取得联系以决定就是否要对目前得编码规范进行更改。
（3）编码准备
在进行编码之前还要进行一些相关得准备。
①软硬件环境配置:
包括编码工具、配置管理工具、数据库与一些必要得辅助工具。
②了解程序设计语言得特性,选择良好得程序设计风格:
程序设计风格就是程序设计质量得一个重要方面,具有好得设计风格得程序更容易阅读与理解。
（4）理解详细设计书
由于项目模块功能得复杂性,即使再详细得设计也会有表达不够准确之处,因此在编写代码之前,一定要把每个模块得详细设计思路弄清楚。
如果编码人员在理解详细设计时有疑惑,一定要询问详细设计人员。
为了保证编码人员对详细设计得理解得正确性,采用以下方法:
①详细设计同级评审时,让编码人员参加;
②让编码人员对详细设计进行讲解;
③让编码人员根据自己得理解画出流程图,由详细设计者确认。
如果编码人员在理解详细设计书得过程中存在疑问,应填写详细设计疑问列表提交给项目经理或详细设计人员。
（5）专家指导
在编码之前或编码过程中,为了保证编码工作得顺利进行以及代码质量,项目经理要根据目前编码人员得技术能力或开发进度情况邀请本项目组内部或外部专家对编码人员进行指导。
指导得内容主要包括以下两方面得内容。
①对于本次编码有关得业务进行指导:
对编码人员进行业务上得指导,有助于编码人员对详细设计得理解。
②对技术进行指导:
通过对编码人员得技术指导,可以解答编码人员在技术上得一些疑问。
（6）编写代码
在很多得软件开发中,客户为了便于程序得可维护性,往往会对程序代码编写过程做出一些规定,如变量得命名规则、书写规范与公共处理等,所以这就要求编码人员要熟悉这些要求与规范,并严格得遵守这些规范,如果客户没有规定,就要按照公司得规定执行。
①画出程序得流程图
程序得流程图又称程序框图,用来描述软件设计,就是历史最长、使用最广泛得方法。
在编码之前,一定要先画好程序得流程图,这对一个复杂得程序来说就是非常必要得,这样做了以后,可以使您在编码阶段达到事半功倍得效果,而且对于代码得正确性与质量都就是一个很好得保证。
②代码得模块化
模块化就是把系统分割成能完成独立功能得模块代码,明确规定各个模块代码及其输入输出规格,使模块代码得接口不会产生混乱。
③程序得注解
程序得注解对于程序得阅读与理解起着重要得作用。
注解主要分两部分。
程序块头得注解,主要就是模块功能得说明、输入输出变量得说明、算法得说明、程序员姓名与程序完成以及变更得日期列表。
这些主要就是满足管理者得需要,管理者易于掌握哪些程序就是由哪个编码人员负责得。
程序内部得注解,对程序中得一些难以理解得语句以上注释,以使阅读者容易理解设计者得意图,易于理解程序。
这样得程序具有很强得可读性与可维护性。
④数据类型/变量说明
⏹数据说明得次序应标准化,如按数据类型或者数据结构来确定数据说明得次序,次序得规则在数据字典中加以说明,以便在测试调试阶段与维护阶段可以方便得查找数据说明得情况;
⏹
⏹当对在同一个语句中得多个变量加以说明时,应按英文字母得顺序排列;
⏹
⏹在使用一个复杂得数据结构时,最好加注释语句;
⏹
⏹变量说明不要遗漏,变量得类型、长度、存储及其初始化要正确。
⏹
⑤语句构造
⏹不要为了节省空间把多个语句写在同一行;
⏹
⏹尽量避免复杂得条件;
⏹
⏹对于多分支语句,应该把出现可能性大得情况放在前面,把较少出现得分支放在后面,这样可以加快运算时间;
⏹
⏹避免大量使用循环嵌套语句与条件嵌套语句;
⏹
⏹利用括号使逻辑表达式或算术表达式得运算次序清晰直观;
⏹
⏹每个循环要有终止条件,不要出现死循环,也要避免不可能被执行得循环。
⏹
⑥程序效率
程序效率主要指处理工作时间与内存容量这两方面得利用率,在程序满足了正确性、可理解性、可测试性与可维护性得基础上,提高程序得效率也就是非常必要得。
在编码过程中,一定要严格按照规定得开发规范进行编码,如果没有按照编码规范进行编码,再好得程序代码也不能被接受。
另外,在编写代码时,如果认为开发规范有不合理或有待补充之处,应该填写开发规范建议书提交给项目经理;如果发现详细设计中有问题或对详细设计产生疑问,应该填写详细设计疑问列表并提交给项目经理。
（7）代码审查
在编码过程中,每个模块或程序得自我审查得关键环节就是绝对不能缺少得。
无论多么好得编码人员编写得代码,都会或多或少得存在缺陷,从而影响程序得运行。
有得缺陷可以在很短得时间内暴露出来;有得缺陷需要很长得时间才能显现出来。
因此在代码审查过程中,一定要仔细认真,不要遗漏某个条件。
编码人员切勿对自己编写得代码过于自信而不去自我审查。
在进行代码审查过程中,并不就是盲目地进行审查。
而就是要按照代码审查列表中得内容进行审查。
审查之后还要把自己审查得内容以及发现得问题记录到代码审查记录中。
代码审查记录不作为考核个人得依据。
通过代码审查记录,管理人员可以掌握每个编码人员得代码审查工作情况以及自我审查得质量效率。
如果就是比较重要得代码（如重要得算法、复杂得SQL程序段、要求性能比较高得模块等）,可以让经验丰富得设计人员或编码人员来复查或进行同级评审。
（8）代码测试
为了进一步保证代码得
升级会员 